This week we:
- Created a service blueprint of our platform, both from the investor’s and the borrower’s perspectives
- Churned our ideas of the loan process into a process diagram (or two)
- Took a deep-dive into the details of the PSD2 regulation, and answered some of our questions regarding the possibilities and limitations of it
On Friday we gathered together to create a service blueprint of our platform. Since, we have two sides in our platform, and thus two different service experiences, we obviously had to build the service blueprint for both of them. That was really interesting because it allowed us to figure out our front-office- and back-office processes that are responsible for the fulfilment of our customer value proposition. Of course, the service blueprint models our processes on a quite high level of abstraction, but it’s essential to know what processes actually form our core capabilities. That is an important first step in order to understand our operations, but it is also an important tool for us to communicate our business model to our stakeholders. In particular, one of our next steps is to reach out to experts to find out what they think about our business model. Are we practically a bank, fund or something else? Having a proper process chart will be necessary to communicate our idea to these people.
After stumbling from conference room to conference room, we finally found a place to work. And even though we had small manpower, work we did. We focused on high level processes and in just 2.5 hours we had worked out the basic structure of the loan assessment and loan process.
We took a deeper dive into PSD1/2 and what is possible in this front. We found out that at least 90 day history of transactions is possible to retrieve. This hopefully allows us to make sufficient evaluations about the risk level of the borrower. To increase the precision, we can include things like public social media info as well as the more traditional credit rating. These will require more digging into regulations.
Combining all the information to a single number ( risk evaluation ) might prove to be quite hard without a frame of reference. Machine learning might be the answer here: if someone with very similar history has behaved in a certain way, it might be reasonable to predict someone else’s behaviour based on that. Some of our team members are already familiar with the field, so they will ponder our possibilities regarding that in the weeks to come.
What happens when someone wants a loan? How does our process work on our platform? Lauri and Saska tackled this one quickly, but reliably.
Connecting borrowers and lenders is reasonably easy – but be want to be in the middle of the connection, keeping the two sides apart. This causes a risk for us, which we naturally want to minimise. Although some safeguards were mentioned we didn’t settle on any just yet – basically the idea is to balance money so, that it covers expected fluctuations on the side of investors ( leaving the platform, being idle and not investing more ) and keeps enough money in circulation to keep the interest coming in.
PSD2 security measures
We tore through some white papers and articles regarding the regulation, such as this one, and made sure that our assumptions and previous knowledge were in line with reality. For one thing, the security measures regarding PSD2 services are strong (as expected): PSD2 implements a new authentication standard, SCA (Strong Customer Authentication). Essentially this is 2FA (two-factor authentication) taken a step further: it requires the user to essentially use two authentication methods for a single login (like 2FA), but these authentication methods must be of different types. So where e.g. inputting a password and then confirming it with a pin would be sufficient in terms of 2FA, SCA would require a user to use two inherently different elements of knowledge. The different types include:
- knowledge (e.g., PIN/password)
- possession (e.g., smart phone, hardware token)
- inherence (e.g., biometrics)
According to the blog post by RSA, in order to not hinder user experience, this type of strong authentication would only be used in some cases: for example, when a user first authenticates a given third party to access their account information. Any successive requests for the same type of info can then be approved with a lower standard of security, by e.g. inputting a pin code or password. There is also a cutoff amount for transactions that don’t need to use strong authentication, ranging from 30€ to 150€ depending on the type of transaction, so small amounts can be transferred with minimal hassle. Taking a close look at these limitations is important: while it is of upmost importance that security standards are high, strong authentication, by nature, is intended to make it harder for someone to authenticate themselves, and thus takes a toll on overall user experience. Small things like setting our recommended investment amount to something that falls below the SCA cutoff amount might make a big difference in terms of UX.