The state of security in the UK P2P lending landscape

With interests rates at all time lows, and market uncertainly making it harder these days for individuals and businesses alike to obtain loans and credit from high street banks, or to achieve a decent return on their savings, more and more people are turning to Peer-To-Peer (P2P) lending.

What is P2P lending?

P2P is the practice of lending money to individuals or businesses through online services that match lenders directly with borrowers. Since P2P lending companies operate entirely online, they have lower overheads and so provide services more cheaply than traditional financial institutions. As a result, lenders typically earn far higher returns (>10% in some cases) compared to traditional savings and investment products offered by banks (<0.5% in most cases!), while borrowers can borrow money at lower interest rates, even with poor credit histories, as loans are often secured against assets such as property, jewelry, high-end cars, or fine art.

The P2P lending industry within the UK has literally exploded over the last few years, with new P2P companies popping up almost every other week. Zopa was the first company in the world to offer peer-to-peer loans back in 2005, but today there are well over 40 companies offering peer-to-peer loans in the UK alone, collectively lending in excess of £3bn a year to consumers and businesses. This year also saw the launch of the new “Innovative Finance” Individual Savings Account (IFISA), which has already proved in great demand, and its popularity is set to grow significantly in the next financial year.

Popular UK-Based P2P Companies:

(in alphabetical order)

With the explosion of P2P lending companies in the UK over the past couple of years and their continuing rise in popularity among individuals and businesses, I thought it about time to take a closer look into some of their security practices and how well equipped they are to be handling and processing personal and financial information.

I researched a number of observable security-related factors on the 39 P2P companies listed above on a single day in February 2017, and the results were pretty shocking!

The key factors analyzed were:

  1. Password Policies
  2. Account Disclosure via Password Reset
  3. Server Software Fingerprints
  4. SSL & Security Header Reports
  5. Cookies, Local & Session Storage
  6. 2-Factor Authentication
  7. Email Communication
  8. Website Communication

Password Policies:

Firstly, let’s take a look at each site’s respective “Password Policy”. A “Password Policy” is a set of rules a site enforces when a user first sets their password when signing up, or when changing it at a later stage, to ensure that strong, complex passwords are chosen.

Site Minimum Password Length Maximum Password Length Must contain at least 1 UPPER CASE letter Must contain at least 1 lower case letter Must contain at least 1 number Must contain at least 1 special character Must NOT contain 1 cross cross cross cross 1 cross cross cross cross 1 cross cross cross cross 1 cross cross cross cross 1 cross cross cross cross 1 cross cross cross cross 1 cross cross cross cross 1 cross cross cross cross 1 cross cross cross cross 5 20 cross cross cross cross 5 40 cross 1 cross 1 cross 1 cross 1 6 65 cross cross cross cross 6 cross cross cross cross 6 cross cross cross cross 6 20 tick 2 tick cross 6 tick tick tick cross 6 tick tick tick cross 6 50 tick tick tick tick Spaces 7 20 tick tick tick cross 8 cross cross cross cross 8 cross cross cross cross 8 cross cross cross cross 8 cross cross cross cross 8 cross 3 cross 3 cross 3 cross 3 8 200 tick cross tick cross 8 tick cross tick 4 8 20 tick tick tick cross 8 200 tick tick tick cross 8 tick tick tick cross 8 tick tick tick cross 8 tick tick tick cross 8 tick 2 tick 4 8 50 tick tick tick 4 8 70 tick tick tick 4 8 25 tick tick tick tick 8 128 tick tick tick tick 8 tick tick tick tick 8 tick tick tick tick 10 tick tick tick tick < or >

1 No password complexity actually enforced despite on-screen complexity hints
2 1 letter required (irrespective of case)
3 Warns against “common”/weak passwords, but will still allow an all lower case, all upper case, or all number password
4 1 number OR 1 symbol required


These days, “strong” passwords are generally considered to be those which are at least 12 characters in length, and which contain random characters including a mixture of upper and lower case letters, as well as numbers and special characters. For example “password” is considered very weak and easily guessable/crackable, where as something like “Hf-wefi^x(7J” is considerably stronger and harder to guess/crack. A good Password Policy is one which enforces the use of strong passwords.

19 out of 39 companies analyzed (49%) allow passwords of less than 8 characters in length, but more astonishingly, 9 out of the 39 (23%) allow single character passwords! Anything below 8 characters is pretty unacceptable, but passwords that can be just a single character are asking for trouble!!

FundingEmpire came out the best, in respect to being the only site analyzed to enforce a minimum password length of over 8 characters (10 in their case). However, FundingEmpire also prohibit the use of < and > symbols in passwords (and LendLoanInvest strangely prohibit spaces in passwords!)

Be wary of sites which prevent you from using certain characters/symbols in your password,as this can be an indication that the site is not storing passwords securely!

Be also wary of sites which limit the maximum length of password you can use to some seemingly arbitrarily low value. If password storage is done correctly, there shouldn’t actually be a need to enforce a maximum password length.

Finally, it’s a little sloppy of sites like FundingKnight and LendInvest to display on-screen warnings about weak passwords or those which don’t meet their minimum requirements, but then not actually enforce this when it actually comes down to it!

Account Disclosure via Password Reset:

Account Disclosure via Password Reset is a method by which anyone can find out if anyone else has an account with a particular site or service by simply entering the person’s email address into the site’s “Password Reset” feature, and seeing what’s returned…

Here’s how the 39 sites performed:

Site Account Disclosure? cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross


Thankfully, none of the 39 sites analyzed appear to offer a way for a user to “retrieve” or “recover” an existing lost password. This would be bad, as it would mean that the user passwords were being stored in a way that they could be retrieved (i.e. in plain text).
There’s evidence that were engaged in this practice as recently as June 2016, according to this thread in the P2P Independent Forum.

Today, all 39 sites instead offer a password “reset” function. However, 25 out of the 39 sites analyzed (64%) revealed account disclosures via password resets. This means that when entering an email address on their respective “Reset Password” pages, the sites then reveal whether an account is registered with that email address: - account disclosure – one of the 25 sites getting password resets wrong!

The correct behavior should be for the site to display the same resulting message on-screen after entering an email address, regardless of whether a matching account was found or not:

Correct way to handle password reset requests – one of the 14 sites getting password resets right!

Server Software “Fingerprints”:

Web Servers should disclose as little information as possible about their underlaying server architectures and software that powers them in the http response headers that are returned when you access a web page on the server.

Why? Well, if an attacker knows precisely what server, software, and software versions a website is running it can expose a possible attack vector.

For example, if a vulnerability/exploit is found in “Server v1.0.0”, which the developer in turn fixes and releases a “Server v1.0.1” update, websites which continue to run “Server v1.0.0” and don’t update to “Server v1.0.1” remain vulnerable to the exploit.

An attacker, knowing of the existence of the vulnerability/exploit in “Server v1.0.0” could simply search the internet for websites running “Server v1.0.0” software and launch an attack.

Therefore, ideally, a web server should not disclose anything about the product name or the product version of the server software it’s running.

Here’s how the 39 sites performed…

Site Server/Application Disclosure Apache/2.2.22 (Debian), W3 Total Cache/, mod_pagespeed Apache/2.2.22 (Debian), W3 Total Cache/, mod_pagespeed Apache/2.2.31 (Unix) mod_ssl/2.2.31 OpenSSL/1.0.1e-fips mod_bwlimited/1.4 Apache/2.4.10 (Amazon) mod_wsgi/3.5 Python/2.7.5 Apache/2.2.22 (Debian), W3 Total Cache/ Apache/2.4.7 (Ubuntu), PHP/5.5.9-1ubuntu4.7 Microsoft-IIS/8.0, ASP.NET 4.0.30319 Microsoft-IIS/8.5, ASP.NET 4.0.30319 Apache/2.4.10 (Debian), Drupal 7 Apache, PHP/5.4.45, Joomla! 2.5 Apache/2.4.7 (Ubuntu) Apache/2.4.18 (Ubuntu) Apache, PHP/5.5.38 Apache, PHP/5.3.29 nginx/1.8.1, Express nginx, Drupal 7 nginx/1.11.4, PHP/5.6.27 cloudflare-nginx, PHP/5.6.30 nginx/1.6.2 Apache-Coyote/1.1 AmazonS3 Google Frontend cloudflare-nginx cloudflare-nginx cloudflare-nginx cloudflare-nginx cloudflare-nginx nginx nginx Apache Apache nginx nginx Apache Apache nginx cross cross cross


The above information was obtained by simply viewing the http response headers when accessing a page on each of the 39 sites. For instance, the http header “X-Powered-By”, if present, reveals information about the server which served the request. Additional headers, like “X-Generator” and “X-Content-Encoded-By” reveal further information about other server software.

Ideally, servers should not return any of these headers.

Only 3 out of 39 sites analyzed (8%) do not disclose any information about the underlaying server.

16 out of 39 sites analyzed (41%) only disclosed the core server product (i.e. “Apache”, “nginx”, etc), but didn’t disclose anything further like specific version numbers. (As a side note, it should be noted that some systems (i.e. Apache when configured via cPanel/WHM) do not allow the “X-Powered-By” header to be fully suppressed, but instead set to just return “minimal” information such as “Apache”)

The remainder of the sites analyzed (51%) disclosed significantly more information, including server software version numbers, PHP versions, operating systems, installed modules, etc.

For reference, at time of analyzing the above 39 sites, the most recent versions of some of the products disclosed are as follows: (so you can see whether the above sites run up-to-date or outdated software!)

  • Apache: 2.4.25 (Released 20 December 2016)
    [The latest version of the legacy 2.2.x branch is 2.2.32, released 13 January 2017]
  • PHP: 7.1.1 (Released 19 January 2017)
    [PHP 5.5 reached it’s End Of Life (EOL) on 21 July 2016, PHP 5.4 reached EOL on 3 September 2015, PHP 5.3 on 14 August 2014]
  • nginx: 1.11.10 (Released 14 February 2017)
  • Microsoft-IIS: 10 (Released 25 July 2015)

As you’ll see if you compare these latest releases with the information disclosed in http headers from the sites above, many are running older versions, including some which are running software which has since reached its “End Of Life” and therefore is no longer supported or updated by the vendor.

It’s always important to keep server software up-to-date not least of all to ensure you’re protected against any exploits/vulnerabilities that may have been uncovered in previous versions of the software, but which have since been addressed with a software update.

SSL & Security Header Reports:

This section looks at various SSL/TLS, https, security headers, and certificate issues…

Site SSL Labs Grade Security Headers Grade SSL Cert Type Other Domains Sharing Cert Mixed Content? TLS 1.0 Support Dropped? Notes F F DV Server vulnerable to the OpenSSL Padding Oracle vulnerability (CVE-2016-2107) and insecure. Server accepts RC4 cipher F D EV Server vulnerable to the OpenSSL Padding Oracle vulnerability (CVE-2016-2107) and insecure. Server accepts RC4 cipher. C F DV YES Server vulnerable to the POODLE attack. Server supports weak Diffie-Hellman (DH) key exchange parameters. Server accepts RC4 cipher C F EV Server supports only older protocols, but not the current best TLS 1.2. Server accepts RC4 cipher. Server does not support Forward Secrecy C E DV Server vulnerable to the POODLE attack C E EV 1 Server vulnerable to the POODLE attack. Server supports weak Diffie-Hellman (DH) key exchange parameters. Server accepts RC4 cipher. Site uses CloudFlare and therefore was vulnerable to CloudBleed B F EV Server supports weak Diffie-Hellman (DH) key exchange parameters B F EV YES Server accepts RC4 cipher. Server does not support Forward Secrecy B E DV 1 Server supports weak Diffie-Hellman (DH) key exchange parameters A- F DV YES Server does not support Forward Secrecy A- F DV Server does not support Forward Secrecy A- D EV Intermediate certificate has a weak signature. Server does not support Forward Secrecy A F DV A F DV A F DV 11 Site uses CloudFlare and therefore was vulnerable to CloudBleed A F DV Site uses CloudFlare and therefore was vulnerable to CloudBleed A F DV 23 Site uses CloudFlare and therefore was vulnerable to CloudBleed A F DV A F DV 57 A F DV A F EV A F EV A F EV A F EV A F EV A F EV A F EV tick A F EV Site uses CloudFlare and therefore was vulnerable to CloudBleed A E DV Intermediate certificate has a weak signature A E EV A E EV A D DV 22 Site uses CloudFlare and therefore was vulnerable to CloudBleed A D EV A C DV Site uses CloudFlare and therefore was vulnerable to CloudBleed A+ E DV A+ E EV A+ E EV A+ D EV tick A+ C DV


SSL Labs Grade
SSL Labs Server Test is a free online service which performs a deep analysis of the configuration of any SSL web server on the public Internet. Sites are graded from A+ to F (with F being the worse)

2 out of 39 sites analyzed (5%) are exposed to the OpenSSL Padding Oracle vulnerability (CVE-2016-2107)
2 out of 39 sites analyzed (5%) are vulnerable to “POODLE” attacks

Security Headers Grade is a free online service which analyzes the HTTP response headers of any web server on the public Internet, and checks whether key security headers are set. Sites are graded from A+ to F (with F being the worse)

SSL Certificate Types
There are essentially 3 types of security certificates for domains:

  • DV (Domain Validated) certificates are verified using only the domain name. Anyone can obtain a DV certificate without needing to prove their own or their business’ identity.
  • OV (Organization Validated) certificates require more validation than DV certificates, but provide more trust. To obtain an OV certificate, the issuing authority will verify the actual business that is attempting to get the certificate. The organization’s name is also listed in the certificate, giving added trust that both the website and the company are reputable.
  • EV (Extended Validation) certificates provide the maximum amount of trust to visitors, and also require the most effort by the issuing authority to validate. Extra documentation must be provided to issue an EV certificate. As in an OV certificate, an EV certificate lists the company name in the certificate itself, However, a fully validated EV certificate will also show the name of the company or organization in the address bar itself, and the address bar is displayed in green. This is an immediate, visual way that visitors can know that extra steps were taken to confirm the site they’re visiting – which is why most large companies and financial institutions choose EV certificates.

Domain Validated Certificate – an example of a DV certificate

Extended Validation Certification – an example of an EV certificate, confirming the site’s authenticity as “Funding Circle Ltd [GB]”

Sadly, only 20 out of 39 sites (51%) currently have EV certificates.

Common Certificates
SSL Certificates should only be issued to the single domain they’re intended for (and its subdomains where necessary). A certificate should not be issued that’s valid for multiple unrelated sites.

Below are the non-connected sites that the above offenders share a common certificates with. Certificates issued by Cloudflare seem to be the worst offenders – for instance, the certificate for is also valid for 11 unrelated domains (including a gay porn site), the certificate for is also valid for 22 unrelated domains (including a string of adult massage parlors in London), the certificate for is also valid for 23 other domains (including one which redirects to an adult dating site), and the certificate for is also valid for 57 unrelated domains (including a casino). Here’s the full breakdown:

  • shares a common certificate with
  • shares its certificate with
  • shares its certificate, (Adult Massage centers in London),,,, (Occpational Health Advice),, (Computer show),, (Small Business Marketing),, (Event Services),,,,, (Chinese blog),, (Analytics),, (Japanese Entertainment forum),
  • shares a common certificate with, (A band/music group), (an 18+ mafia game – in Bulgarean), (Church music backing tracks), (Free HD gay porn),, (Norwegian building supplies), (Screen capture tool), (an 18+ mafia game), (a mafia game for UEA), (car wiper blades – New Zealand), (car wiper blades – Australia)
  • shares its certificate with,, (Turkish clothing store),,,, (Russian MP3 site),, (Kazakhstan craft supplies),,, (Music download site – Russian),, (Personal website), (Music download site – English), (WordPress blog), (Online payment processor), (Pizzeria in Germany),, (Hungarian camera shop),,, (Redirects to adult dating site),
  • shares a common certificate with (Website services), (Casino), (French “Just Eat), (Laboratory supplies), (Mexican cable company), (Brazilian pensions provider), (biopharmaceutical company), (Church management system), (IT security company), (Financial services software), (Fitness products), (Airline), (Cosmetics), (German online retailer), (Australian online retailer), (Car rental), (Travel agent), (Technology review site), (Running event), (Online children’s retailer), (Website services), (Software vendor), (Currency exchange), (Spanish social network),, (Nutrition/Health Science), (Office Supplies), (Redirects to, (Online school payment processor), (Online payment processor), (Software vendor), (Competition), (Healthcase assessments),, (French insurance provider), (Software vendor), (Insurance broker), (Couth Carolina Ports Authority), (Coupon site), (Technology product),, (Financial comparison site), (State of California Employee site), (Credit Union),, (IT solutions), (Financial news),, (Shopping Channel), (Dental insurance), (Medical supplies), (Estonian insurance provider)

Mixed Content?
All content on secure https sites should be served over secure https. If some resources are served over secure https and others over insecure http on the same page, this is known as “Mixed Content”, and is dangerous as it increases the vulnerability of the page to an attack. 3 of the 39 sites analyzed (8%) attempted to serve mixed content on their homepages when tested.

TLS 1.0 Support Dropped?
Transport Layer Security (TLS) 1.0 is over 20 years old and no longer considered secure by today’s standards. Furthermore, from 2018, supporting TLS 1.0 will break PCI compliance, so sites handling financial data like the P2P sites covered here, will need to deprecate TLS 1.0 support if they’ve not already done so.

At time of writing, only 2 of the 39 sites analyzed (5%) have deprecated TLS 1.0 support. More worryingly, one site ( currently ONLY supports TLS 1.0 connections (and not the newer 1.1 and 1.2 specifications) and currently still support obsolete SSL2 and SSL3 connections, making them vulnerable to the highly publicized “POODLE” attack, first uncovered back in 2014.

No redirect to https:
Pages on can be accessed via insecure http. All pages on secure sites should be accessible via https only. This flaw means that’s login page can be accessed insecurely (, making it vulnerable to Man-In-the-Middle (MITM) style attacks.

Until recently, pages on (including login and register pages) could also be accessed via insecure http. have since fixed this.

CloudFlare Usage:
At time of analysis, 7 out of the 39 sites (18%) utilized CloudFlare services (according to Between September 2016 and February 2017 sites using CloudFlare’s infrastructure were vulnerable to a memory leak which could lead to HTTP cookies, authentication tokens, HTTP POST bodies, and other sensitive data being disclosed (and also cached by search engines). CloudFlare state the number of affected customers was small, and their incident report may be viewed here.

At time of writing, have since stopped using CloudFlare services. commented in the P2P Independent Forum on 2nd March: “We received an email from Cloudfare 24 February 2017 with a confirmation that the account responsible for and were not effected by the issue.”

However, there is presently no evidence that or the 6 other P2P sites that have been/are currently utilizing CloudFlare services have reached out directly to their user base to provide them with further information, or to prompt them to change their passwords as a precaution where necessary.

Active Links to test/developer sites
On’s site, the “Login” link for users at the top of each page points to:

However, the “Login” link at the bottom of each page points to what appears to be collateral’s “test” server (

Whilst this is the result of carelessness and sloppiness on the part of their developer(s), it should also serve as a lesson to users: Whenever you see a “login” button/link on a website, check the domain of the page you’re currently on before you click, and compare that with the resulting domain after you click. Commonly, the two domains should be the same (or the resulting domain should be a subdomain of the original domain i.e. “secure” or “members”, etc). If you’re redirected to a completely different domain all together after login – (especially if the domain has the word “test” in it!) – this should raise alarms bells!

Old website versions remain active/online
Again, racks up another security failure in that an older version of their site continues to remain online and publicly accessible via

For security, companies should ensure that any old versions of their websites are removed/made not publicly accessible. There have been numerous incidents of security breaches where hackers have gained access via old or obsolete sites, systems, and databases that the business may forgotten were still online.

Cookies, Local & Session Storage:

Storing personal/financial data unencrypted in a user’s own web browser (in a cookie or through Local/Session storage) is a big no-no. Also, cookies on sites dealing with financial transactions should have the “Secure” flag set (so that they only apply over secure connections), and the “httpOnly” flag set (so they can’t be accessed via client-side scripting)

Site Cookie Notes Local/Session Storage Notes Not all cookies set with Secure and HttpOnly flags No Secure or HttpOnly flags set Email/Gender/DOB/Postcode stored in plain text in Local Storage Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags No Secure or HttpOnly flags set Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags No Secure or HttpOnly flags set No Secure or HttpOnly flags set Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Email stored in plain text if “Remember Email” option selected No Secure or HttpOnly flags set No Secure or HttpOnly flags set Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags No Secure or HttpOnly flags set Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags No Secure or HttpOnly flags set. User email stored in plain text Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Not all cookies set with Secure and HttpOnly flags Email address stored in plain text if “Remember Me” option selected


Setting “Secure” and “HttpOnly” flags on cookies is such a simple thing to implement for improved security, but it’s surprising just how many sites aren’t setting these two flags!

Unbolted set a 20-year cookie (_custom_data_email) containing the user’s e-mail address in plain text, MarketInvoice and Zopa also store a user’s plain text email address in LocalStorage (which never expires, unless manually cleared, or its value changes by the website which set it) when “Remember Me/Email” options are selected upon login.

But even more worrying, Abundance store a lot of juicy personally identifiable data, unencrypted in the user’s browser’s LocalStorage:

Quite why Abundance store such information in a user’s browser is unknown.

2-Factor Authentication:

Passwords in themselves are far from ideal. If someone knows/guesses your password, they have access to your account. To help combat this, a concept called 2-Factor Authentication (2FA) was devised. Under 2FA you “login” to a website/service using both a password (i.e. “something you know”) and a hardware device/token/key fob/smart card etc (i.e. “something you have”). This means that even if someone has your password, they’ll be unable to access your account as they don’t possess the second factor.

2-Step Verification (2SV) is not the same as 2FA – in fact, for all intents and purposes it’s no more secure than a simple password. Under 2SV you enter your password and either a pin or the answer to a security question (i.e. “Where did you grow up?”). As you know all these things (and therefore so could someone else), it offers no additional security benefit. For example whether your password was “password1234”, or your password was “password” and your pin was “1234”, it’s six of one and half a dozen of the other!

Site Supports 2FA? cross 1 cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross cross 2SV (Security Question) 2 2SV (3 letters from memorable word) 2SV (5 Digit Pin) 2SV (Security Question) 2SV (Security Question) 2SV (Security Question) 2SV (Security Question) 2SV (Security Question) 2SV (Security Question) 2SV (Security Question) tick 3 tick 3 tick 3

1 Ablrate’s Privacy Policy makes reference to “security questions”, however, these are not implemented on their site (Perhaps their Privacy Policy was copy & pasted from another site?!).
2 Security Question is only used when resetting a lost password
3 2FA is optional and not enabled by default


Currently, only GrowthStreet, RateSetter and SavingStream offer a 2FA method (by sending an authorization code to your mobile phone via an SMS message each time you login). However, this is only optional on all platforms and isn’t enabled by default.

A response on this from “Kevin” at RateSetter on the P2P Independent Forum stated:
“If you want you can add mobile 2-factor authentication, i.e. every time you log in you must also add a mobile number code we text you. Unique every time, so a fraudster would need to know your email, password and have hold of your physical mobile phone.

This isn’t mandatory as RateSetter doesn’t think it required … I personally don’t use the 2-factor functionality.”

Given these platforms are similar to your online banking in that they handle your online transactions – shouldn’t their security be comparable?!

Email Communication:

I reached out to all 39 P2P companies analyzed and politely asked them the following questions in order to gain a better understanding of their approaches to security:

  1. Do you outsource development of your website, or is development fully in-house?
  2. How do you store passwords and other personal information of your users? (i.e. what encryption methods are used?)
  3. Does your site support 2-factor authentication (2FA)?
  4. Has your site/infrastructure undergone a professional independent 3rd party security audit? If so, are you able to provide evidence of this?
  5. Have you ever had a security breach of your IT infrastructure?
  6. Do you have a dedicated in-house security contact within your organisation that I can convey some security concerns to?

I was interested in their speed of response, and how open & transparent they were about their security practices, and eagerness to learn of the security issues I’d identified.

I purposefully contacted each of them outside of office hours on a Saturday morning between 11am-12.30pm. Contact was made via their published contact email address, or where not available via a contact form on their website.

Here are their respective response times:

Site Initial Human Response Time 42 Minutes 81 Minutes 46 Hours 47 Hours 48 Hours 77 Hours 5 Days No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response No Response


A company (particularly one storing personal/identity information and handling financial transactions) who receives an email where an individual wishes to report and disclose security concerns/vulnerabilities regarding their website/servers should be reactive and the report treated seriously and investigated promptly – even if received outside of normal working hours. Waiting several days before acknowledging and responding to the potential issues raised is very bad. During this time, their inaction and complacency could lead to vulnerabilities continuing to be exploited before they’re addressed.

Most reputable companies which welcome reporting of security concerns and vulnerabilities will have a dedicated email address (i.e. security@….), and maybe even run a “bug bounty” program to further encourage the responsible reporting of vulnerabilities.

Secondly, if a company is implementing their security correctly and taking it seriously, they should have no issues answering the kind of questions I asked. Inability to answer such basic questions demonstrates paranoia and a lack of understanding of basic security fundamentals.

For example, if a business is confident that they are storing passwords securely, they should have no hesitation revealing the method by which password are encrypted – because if they’re secure, then they really have nothing to worry about in making that knowledge public!

Here’s a great example from Dropbox who are totally open and upfront about how they encrypt and store user passwords – because they’re confident they’re doing it securely!

So if a business won’t give you straight answers when it comes to security and won’t tell you exactly how they’re storing passwords, they either don’t know (perhaps because they outsource their platform development, and don’t bother to check!), or they’re not confident that they ARE actually storing passwords correctly!

Here are the limited responses I received following my reaching out to all 39 companies:


Abundance initially responded requesting more information on the article I was writing, which I was more than happy to provide. In turn, they then provided me with a security contact and the following answers to my questions:

  1. “Our platform is developed fully in-house.”
  2. “Passwords are subject to industry standard crypto (salted hashing). Our database is not currently encrypted at rest (reviewed periodically). We don’t store any payment information. Data is anonymised before it reaches any third party services (analytics etc).”
  3. [Our site does not currently support 2-factor authentication] “but it is something we’re reviewing and may look to adopt in the future. 2FA is built into all admin systems.”
  4. “Our website undergoes periodic pen testing by an accredited third party, and we conduct periodic independent audits on our underlying infrastructure. The reports are for internal use only I’m afraid.”
  5. “We have never had a security breach of any of our infrastructure.”

Abundance should be congratulated here for being the only one of the 39 P2P lending companies approached to provide responses to each of my queries.


Ablrate responded: “Thank you for your enquiry recently and our apologies in the slight delay in responding. All our platform security is managed in-house and we find that the most effective control of all data and operational process’s. Unfortunately we are unable to assist you in your research and wish you all the best.”


ArchOver responded: “Do you seriously think we would be foolish enough to respond with answers to this kind of query?”


To give Collateral credit, they were the quickest to respond to my initial email – just 42 minutes on a Saturday – which is impressive! However, it should be noted just how difficult it was to initially make contact with them in the first place as they don’t publish a contact email address on their website, and their “contact us” form was broken at the time I tried to use it too! (I eventually found an email address for them via google)

Their initial response was less than satisfactory: “For obvious security reasons we won’t discuss security measures via email. If you would like to make an appointment to come in and see us we are more than willing to alleviate any concerns you may have.”

I’d never come across another company who would only engage on security matters “in person”! It would be like having to travel all the way to San Fransisco to raise security queries with Facebook, or to Washington to raise them with Microsoft! – Crazy!

I raised this point with them, and they in turn then wanted to know whether I was an investor with them, and if so what my investor ID was, and why I was asking questions of their security.

I explained that whether I was an investor or not was largely irrelevant to whether they answer my questions or not, but explained why I was asking these questions, and pointed them to this blog. I also went on to disclose various issues I’d identified with collateral’s website.

“Peter” from Collateral responded: “I have passed your emails on to those who have more technical knowledge than me to provide a response back to you.”. Peter also offered to meet in person to discuss further, or to discuss over the phone.

Funding Circle

Funding Circle responded: “Unfortunately as you are not a registered investor with us, I am not able to send this information to you directly. However, I have passed your message to the relevant department. They will be in touch if this is of interest to them.” …security is obviously not of interest to Funding Circle, as since then, I’ve heard nothing further for their “relevant department”.

Octopus Choice

Octopus Choice responded: “Unfortunately I’m not able to discuss our security approaches with you, as I’m sure you understand.”


SavingStream didn’t respond, but do appear to have added me to their investor mailing list!


Zopa responded and said I would need to email their PR department instead, which I did within an hour or two of their email.

7 days later, Zopa contacted me again requesting disclosure of the security issues I’d identified with their platform, which I was happy to provide them with. They didn’t however respond to my original queries, and I’ve heard nothing further from them since.

Website Communication:

Aside from the above responses I received, the following information was also obtained from their various websites: (look out for the pseudo-impressive “tech speak buzz-words” sites use to make what they say sound more impressive than it actually is and give the impression they know what they’re talking about!)


From ArchOver’s own FAQ entry entitled “Is your platform secure?”:
“Yes. The platform has been built upon the recognised industry standard Microsoft.Net software stack. The platform has been designed from the ground up as a scalable, secure and resilient solution. The Microsoft.Net stack provides the strong base grounding for support of scalability and also provides industry tried and test facilities for security.

ArchOver have a full Service Level Agreement with both our development partners Gislen and our hosting partners Ipeer that provides for contingency in the case of server failure or invasion and a robust disaster recovery process.

Our platform has passed a regulated load balancing test for its ability to cope with up to 800% expected activity. It has also passed a focused penetration test to cover off base level attack vectors.”

What does this tell us?
A platform “built upon the recognised industry standard Microsoft.Net software stack” doesn’t automatically mean it’s “secure”. SLA’s with 3rd parties don’t automatically make a site “secure”. Granted an SLA with a “development partner” may allow you a course for recompense in the event of a security breach due to their negligence, but an SLA in itself won’t mean the site has no vulnerabilities. Also, I find it highly unlikely that an SLA with a “hosting partner” would cover against a website’s security issues as a result of poor implementation by a site’s developer. Hosting company SLA’s usually only cover against things like uptime of their service falling below a certain percentage, guaranteed support response times, and may also include regular backups of a site – but they don’t cover against vulnerabilities arising out of poor coding/implementation by the site owner.
Also, the terminology about passing a “regulated” load balancing test is misleading – this implies there is a standard legal test all P2p leading companies need to pass. There is no such requirement, and so the word “regulated” is misleading.
Finally, there’s no mention as to whether the “focused penetration test” was conducted internally (by the same people who develop the site itself), or whether this was conducted externally by an independent professional security firm.

Also from ArchOver’s FAQ entry on “How is my information stored?”:
“ArchOver takes its own security and the security of its customers very seriously.

ArchOver maintains a secure internal back office network running off encrypted lines to our cloud based office systems.

Our transactional platform is hosted in a secure virtual server farm in Sweden, so all data is maintained within the EU to comply with data protection directives.

Data is backed up on an incremental basis daily, and a full backup weekly. Data is only accessible via ArchOver staff and support delegates.

The transactional site uses 1024 bit encryption via HTTPS over the internet. Sensitive data is encrypted at storage. The transactional site is constantly monitored 24/7 for health and attacks. The SLAs in place provide for immediate notification of any service issues or suspicious access.”

What does this tell us?
So no real mention of exactly HOW information is stored, other than it’s “encrypted” in some undisclosed way (note: not all methods are “encryption” are “secure” by today’s standards – that’s why it’s important to know the specific encryption methods a site uses for storing passwords, etc)


From BondMason’s FAQ Entry “What does BondMason do to protect my account and funds?“:
“We aim to do everything we can to protect your funds, and safeguard your account with BondMason. This includes adopting a best of breed approach, working with trusted data centre providers and running regular (and multiple) backups and protecting client data.

If you become aware of a security breach, or potential security breach, please contact us immediately.”

What does this tell us?
Some waffly language here – what exactly is a “best of breed approach“?(!)
The FAQ answer primarily deals with protecting their site from data loss (with regular backups), and not how they actually protect their site/data from data breaches.
Interestingly, the last sentence of their FAQ answer encourages reporting of security issues… as I can testify though (given the lack of response to my email), this is meaningless as they don’t respond!


Perhaps rather than blogging about CyberSecurity, GrowthStreet could perhaps take a look at their own site with respect to CyberSecurity?! (Hint: 1 character passwords are not a great start guys!)


LendLoanInvest published a blog post back in 2013 entitled “We Take Your Security Seriously!” with a nice stock image of the word “SECURITY” on the back of a jacket. The article begins:

“We wish to ensure that users may enjoy the benefits of this site confidently, knowing that their data and transactions are safe secure.
Therefore we have expended much effort to achieve this security.
We also have a zero tolerance to the small minority who wish to spoil it for the many.”

The post then goes on to outline some of their “security measures”, which include:

  1. An EV certificate (although, this isn’t site-wide, as their blog is served over http!)
  2. “SecureLive Anti-Hacker System” – A defunct/abandoned security product – the domain for which (securelive(.)net) now hosts a spam blog)
  3. “We encrypt stored bank details” (no mention of the encryption method though!)
  4. A reference to “HMCE Money Laundering registration”? (I suspect they mean HMRC!)
  5. “Multi-Faceted” Site Operation Security – one of the features of which is “automated backups”. Whilst this will allow the site owner to restore their site to an earlier point it time, it in itself won’t protect against a security breach

LendLoanInvest also have a separate “Risks & Mitigations” article, which briefly touches on how they mitigate the risk of a data breach/attach.

What does this tell us?
An EV certificate is good, and as discussed earlier in this article, instills greater trust in users – however, an EV certificate is not a guarantee that the are no vulnerabilities in a site!
It should be notes that their “We Take Your Security Seriously!” blog post is over three years old now and hasn’t subsequently been updated. It references a now defunct security product, and so it would be interesting to know what (if anything) they replaced this with?


From ThinCat’s December 2016 Newsletter:
“IT has been a priority, and we have improved systems and security, bringing the function in-house, with a significantly expanded team … The in-house Technology team has grown from three to nine over the course of the year”

Their newsletter goes on to say:
“The threat of cybercrime is ever-increasing and at ThinCats we take our responsibilities very seriously. As such, we have had an ongoing programme of system and infrastructure improvements throughout 2016 to address evolving security threats.

As part of that programme, we carried out a full external vulnerability assessment in Spring 2016 and since then have been working to reinforce our security policies and technology with our security partners ZeroDayLab and SecurityAlliance. We will carry out another external vulnerability assessment by the end of this year and will do that regularly going forwards. In 2017 we expect to roll-out enhanced security user login procedures.”

What does this tell us?
ThinCats have brought all their IT in-house within the last year, have had a “full external vulnerability assessment” carried out in Spring 2016, and committed to further regular external security audits.

This is quite encouraging, and is the only platform (other than Abundance) to state they have undergone an external security assessment.


Not one single P2P site out of the 39 analyzed gets everything right when it comes to security. Each one had multiple security failings with various degrees of severity, however, ALL the failings identified here can be readily resolved.

The fact that many quite basic fundamental security issues exist across the UK P2P lending landscape, makes me wonder just how much “in-house” security knowledge and expertise some of these P2P lending businesses have?

Many of the smaller P2P platforms are run by very small teams of people – some are run with just 2-3 members of staff, working standard office hours Monday-Friday, with some clearly “outsourcing” their website development completely to 3rd party developers.

Whilst there’s nothing wrong with outsourcing IT/Website development if you lack the necessary skills and expertise in-houses, how can you then adequately assess and monitor whether the people you’re outsourcing to DO have the necessary understanding of and ability to implement suitable security requirements in the financial sector?

From my extensive assessment of a number of security aspects across these 39 P2P sites, I draw the following key conclusions:

  1. It’s apparent that many P2P companies lack dedicated in-house security expertise, nor do they have the ability to respond swiftly and efficiently to security concerns or incidents, especially if they are reported/occur out of hours.
  2. Given the number of very basic security failings, there’s little evidence that many of these companies have undergone professional independent 3rd party security audits of their infrastructure. Such audits would pick up on the issues I’ve identified (and a whole lot more!) and could ultimately save the business a lot of money, expense, embarrassment, and reputation damage if in the future there’s a security breach as a result of their complacency/negligence/incompetence (TalkTalk anyone?!)

Food for thought if you’re tempted by P2P borrowing/investing, IFISAs (Innovative Finance ISA’s), or already borrow or invest through these sites. Whilst you may be getting an enviable rate of return on your investment, or a very competitive rate on your loan, bear in mind that:

  1. P2P lending sites NOT covered by the Government’s Financial Services Compensation Scheme (FSCS) (which protects up to £85,000 of your money in the event an institution goes bust). Your capital is at risk and you could loose everything you invest.
  2. Many P2P companies are yet to demonstrate adequate security competence given the nature of businesses they’re running (financial transactions). The personal and financial details they hold on borrowers and investors alike may not be as secure as borrowers and investors assume they are!

I sadly suspect it’s only a matter of time before a UK P2P lending company suffers a serious data breach as a result of their dismissive and complacent attitude towards security…

I sincerely hope that doesn’t happen, and so my hope is that this blog post serves as a “wake up” call to these companies to get their security affairs in order, and how they respond to security concerns. At the same time I also hope it serves to enlighten borrowers and investors who are members of these and similar sites, and if that’s you, I’d encourage you to challenge these sites on their security approaches!

Responses to this blog post from all P2P lending companies are welcomed and encouraged (particularly from those 32 P2P lending sites which couldn’t be bothered responding to my direct contact!), and this post will be updated accordingly should such responses be received.

UPDATE: A number of platform responses were received after original publication of this article. These are covered in this follow-up article

All information correct at time of analysis in February 2017

0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments