This is THE question your business should carefully be thinking about before presenting your user’s financial data back to them if using another company’s regulatory permissions as an agency.

Why? Because the once ambiguous regulatory perimeters have now become clearer.

The Financial Conduct Authority, the UK’s financial regulatory body, has clarified its AIS [perimeter guidance](https://www.handbook.fca.org.uk/handbook/PERG/15.pdf) on the principal-agent relationship. Basically, what data needs to look like when presented back to your customers.

What kind of businesses should care about this guidance? Any business involved in providing account information services(AIS) to end-users in the UK.

In this blog post, let’s understand what the perimeter guidance means for agent businesses who currently use another company’s license.

## What is an Account Information Service Provider (AISP)? Simple words, please.

An AISP is an online service provider that collects financial information from end users (accounts, balances, transactions..) from one or more banks, either in the format originally provided by the bank or after processing. This is so they can legally display this data back to the end user (eg. the person with the mobile app in their pocket📱) or to another business entity as instructed by the user (eg. a digital brokerage app that asks for your users’ banking data to pass it on to lenders of your user’s choice so that they get a quicker mortgage decision 🏦)

## What is an agent of an AISP?

If you are a business who is not regulated to ask for user data from banks, you tend to rely on a regulated partner company that has FCA permissions to do so. In that case, you pass your user on to your partner’s application that manages connections to banks, gets the user’s permission and shares their data with you. For compliance purposes, in this equation, you are appointed as an agent of this regulated partner in the FCA’s eyes.

## What were the Agent (you) — Principal (AISP) arrangements previously?
![Sitting 2](//images.ctfassets.net/3ndxs7efitel/7oMmkLeTWjFFYLvExRYhOv/2e6c8f17c041c440c68e9f852b97a7f6/Sitting_2.png)

A regulated AISP simply outsources their permissions to service providers (agents) wishing to access open banking. Although end consumers were presented with the regulated party’s interface, this was only restricted to the initial phase of getting permission at the beginning via a co-branded interface. That meant *an agent of an AISP could display data to end-users in their own way as long as they weren’t asking for permission to access the bank.*

## What does the FCA say as part of the agency perimeter guidance clarification?
![Sitting 3](//images.ctfassets.net/3ndxs7efitel/4g4ymiRYQAXWOxYiVwEszi/cef4cce80ccb1688e307db7c3dee126d/Sitting_3.png)

FCA perimeter guidance emphasises that businesses need to be accountable, trustworthy and transparent to their end-users. Since multiple businesses are involved in getting user data from banks, they want end-users to know which business is asking for permission and with whom all is the data shared.

The FCA gives examples of various businesses to explain what an agent can do and cannot do.

## What CAN’T you do by being an agent of your regulated partner?

As per new guidance, the following business activities CANNOT be carried out by an agent business:

1. Your business primarily brands interactions with the end-users asking permission to access their bank
2. Your business displays a user’s bank data in the design and format of their choice — categorised or raw — on an ongoing basis
3. Your business provides additional and independent account information services outside the permissions of your regulated principal partner!

In summary, the new guidance means the agent-principal model is restrictive for agents because it;

- Builds up more __friction in the customer journey__ as there are two containers within an app displaying data to the same user
- __Limits innovative product__ offerings — you cannot continue to offer services outside of, or more than, what your regulated partners can provide

For example, if you are an agent money manager displaying users transactions based on their spending and data is received from your regulated partner, you cannot continue to display data in your own style or format without your own FCA permissions.

## What business can continue as an agent of a regulated AISP?
To summarise, you can continue to be an agent if you don’t have a user-facing application and only use the bank data received from your regulated partner to verify and provide decisioning of some sort.

Typically, you don’t need regulatory permission (AIS/PIS) if:

1. Your business doesn’t interact with users to ask permission to access bank data — it will be displayed in something resembling an iframe
2. You don’t display end-user bank data to them in any format (categorised nor raw)

For example, you are a lender (or a broker who shares data with the lender) that receives your user’s bank data for eligibility/affordability checks and provides a decision such as a loan approval/rejection without displaying the transactions or balance data back to your users.

But wait. There IS an alternative. So what can you do to provide value-added services and display insightful data to your users, on your own? The silver lining is that becoming an independent regulated entity fully owning the customer interaction, app design and most importantly be the sole data protector and processor, is not too difficult! 😎

## How does being regulated instead of an agent impact my customer journey?

1. 🛡️__TRUST__ You can increase your customer adoption! Your customer will now only see your brand end-to-end which will increase trust and transparency.
2. 👤 __USER INTERACTION__ You can completely own your customer interaction and reduce additional dependency on your service providers.
3. 🔒 __DATA SECURITY__ You can be the sole processor, protector of customer data and resolve customer concerns without dependency.

## As much as I like to own customer experience and data security, I don’t fully understand how easy it is to get regulated?

FCA authorisation is not as complicated as everyone thinks and the FCA has been increasingly collaborative and efficient in order to support businesses. Based on our discussions with various TPPs, here’s what we know:

1. Duration: Companies took anything from 2 months to 5 from start to finish!
2. Process: 3 simple steps for authorisation:  
    - A couple of weeks to a month of work to get documents together — A picture is worth a thousand words: be ready to show the visual flow of why using open banking in your app serves and benefits your customers
    - A couple of months for the FCA to ask you questions and make a decision — you don’t need to have everything figured out before you start the application.
    - You don’t even need the capital reserves in the account or the insurances when you submit the application. The FCA will tell you that being an approved subject is conditional on doing X, Y and Z, and you will do it at that point in time.

The sooner you start, the better it is!

## Sounds great! Can Yapily help in any way?

Yes, we can! Thought you’d never ask! 😊

We can primarily help with what we do best — provide a robust connectivity enabler that doesn’t interfere with you, your customer and your customer’s data.

1. __Quick Integration & Expansive Coverage__ — We offer connectivity to all our banks in no time and keep adding new bank APIs as they become available.
2. __Easy Maintenance & Monitoring__ — We maintain secure and scalable API connectivity to all banks so that you can get an optimised, monitored offering from us and instead focus on your core product.
3. __Developer Focus__ — As a true engineering (not financial) company at our core, we focus on your developers’ needs and have everything they need to build simple and easy connectivity — check out our GitHub for guides, SDKs, a ready-to-build payments app and open source code.

Also, we can assist by sharing our regulated customers' experiences!

__All you need to do is say [hello@yapily.com](mailto:hello@yapily.com)__👋

Is your business sitting outside the ‘AIS perimeter’? 🤔

It’s Okay. You’re right to be sceptical.

I was too.

The very idea that those ‘*few lines of code*’ could do such a thing sounds laughable. Bordering on snake oil.

How could it possibly do anything but shuffle a few consent gateways, and automate a fundamentally static financial transaction between two parties? Isn’t it just another buzzword that doesn’t carry any meaningful weight? At best, a nudge for long-term financial sector reform?

Before attending the launch of Nationwide Building Society’s ‘[Open Banking For Good (OB4G)](https://www.openbankingforgood.co.uk/)’ initiative last Thursday evening, I was already a convert to Open Banking.

But the thought of using it — immediately — for the purposes of social advocacy and poverty reduction? Fascinating.

![financial-services 2](//images.ctfassets.net/3ndxs7efitel/3SwrOBL375sWkN3MFWLUAv/a0240da8f73b1b95c2b6e06806a58179/financial-services_2.jpeg)

Accompanied by the gentle whirring of cameras and lights, representatives from the UK Open Banking ecosystem sat and listened as frontline advisers, researchers and charity campaigners from the fields of debt advice, financial wellbeing and mental health spoke about the new frontier. Open banking as *social reform*.

Not only as a route to efficiency savings and innovation (as many still see it), but as something that can help the poorest in society, *right now*.

## How?

As best summarised by one of Citizens Advice’s clients, quoted in a presentation from Senior Policy Researcher Joe Lane (above):

> It doesn’t take much to tip you either under or over

Unplanned financial shocks, coupled with an absence of savings, is enough to drag anyone down. Until it happens to you, the importance of an app that, perhaps discreetly, ‘rounds up’ transactions or warns that you’re overspending suddenly becomes critical.

As explained by the [Money Advice Trust](http://www.moneyadvicetrust.org/Pages/default.aspx) team, who receive hundreds of thousands of calls a year from people struggling with their finances, conversations always take on a structured, no-nonsense financial planning flavour from the outset.

The sooner you put plans in place and get full visibility over your ingoings and outgoings (especially when you have children), managing the fallout becomes easier. But the longer you live wearing a blindfold to your financial situation….? Well, the results are perhaps obvious.

Helen Undy — director at the [Money & Mental Health Policy Institute](https://www.moneyandmentalhealth.org/) — drove home the acute correlation between financial and mental strain.

Most effecting was seeing the relationship between financial difficulty and a lack of impulse control. People have a habit of spending more — recklessly — when their income is at its lowest.

The vicious cycle begins; further money problems consequently creates stress and psychological harm. Repeat.

If so many suicides are caused by financial loss, and our interaction with apps and mobile devices is skyrocketing, open banking applications that keep money management front of mind could well become key to a nationwide mitigation strategy.

Michelle Highman from [The Money Charity](https://themoneycharity.org.uk/) emphasised the importance of positive language. Solutions to financial hardship could well be a problem not of the speed and accuracy of the subsequent support, but the way we approach prevention in the first place.

> People have a habit of spending more — recklessly — when their income is at its lowest.

It’s not enough to simply tell people they need to be careful with money. Terms like ‘*debt prevention*’ are scary, and more likely to disengage people from actively looking at alternative solutions. Open banking needs to give people a sense of wellbeing, of taking control back over their lives, not just their sterilised financial data.

By using this sort of language, you and your users will thrive.

![financial-services3](//images.ctfassets.net/3ndxs7efitel/7fDUvh7ZcLPMtYzvRNlrC7/f9f2793924efc7bac48c38618a34dbaa/financial-services3.png)

Overall, I detected a sense of excitement and energy after the event. All those at Nationwide, The Money Advice Trust, The Money Charity, Citizen’s Advice and the Money & Mental Health Policy Institute should be congratulated for informing, stimulating and indeed humbling the open banking community.

…Here are some take-aways from the event:

## Use Cases

### Quick Decisions

People suffer financial fatigue, and people that need help most abandon the additional ‘form filling’ steps merchants require of them for credit checks. More forms, less applications, less access to credit. Open banking can facilitate both effortless KYC and immediate, accurate affordability checks from historic financial activity.

### Gig economy

The self-employed market in the UK comes with huge opportunities…and risks. The tendency to think month-to-month (natural for anyone with sporadic income) aside from the obvious uncertainty means __pie charts about your spending isn’t enough__. Apps need to think about what financial planning support they can offer over a 8–12 month period and beyond.

### Behavioural science

By tracking and analysing spending habits generated OUTSIDE the scope of your app, you’ll get more traction: Partner with charities and think tanks with data to hand that do this sort of thing __for a living__. Not only would intervention and red flags be easier to build into your product, but, commercially speaking, more accurate, targeted offers and discounts are achievable.

### Government uptake

The wealth of information government agencies, the NHS and HMRC could access via open banking applications goes without saying. Those stakeholders whose responsibility over defining and preventing mental health no longer have to behave reactively to someone’s financial disruption. Such insights can __inform policy directly__ and help connect the dots.

### Self-exclusion

People don’t respond well to red lines and being told off. When building a PFM solution, focus on the subtlety of your messaging. Inception, if you will. You want your users to come to terms with any overspending themselves, and adding visibility over account activity from __parents or trusted friends__ is a good start. Many apps like [gohenry](https://www.gohenry.co.uk/), [Osper](https://osper.com/) and [Nimbl](https://nimbl.com/) prove that the demand and supply are there.

## Challenges

### OB specifications

Not available currently, but getting merchants and banks to develop __tax code and government benefit__ categories would help. This would accelerate one of first checks conducted when someone’s finances require intervention. Checking you’re owed what you’re owed.

### Real-time data

For example, the ability to detect gambling activity — the first instance ever — at 2am on a Tuesday morning, the day after salary debits cease, would give a very clear indication of what could be happening to someone. Authorities or family members would __need this information quickly__, and for it to be as accurate as possible.

### Staying informed

Of all the categories of financial capability that Citizens Advice track between a client’s first and second assessment, ‘staying informed’ __ranked bottom__. The ability to integrate the wealth of Open Data out there on bank products would be a worthy addition to any app seeking to do good.

### Tone

Engaging propositions are dealbreakers for those __sensitive__ to financial mismanagement. To consent to an app — let alone friends and family — seeing your activity requires the correct use of language, design and feel. In theory it’s a sure way to protect people, but in practice? Very difficult.

Open Banking’s social impact alone should be a reason for everyone to work hard to make it a huge success.

__… to debate OB4G use cases, reach out to [hello@yapily.com](mailto:hello@yapily.com) or join the [Yapily](https://www.yapily.com/) slack channel [here](https://yapily.slack.com/join/shared_invite/enQtNDU0MjI4NzEwOTEzLWYwNTEzNjk3NzIyNmUwMWY1ODI1ZTRhZTgzZmQyMDc3NzM4N2Y4YmZjMGY2OWM2ZDYyNDIxMzEwMTkxMWM2NDE).__


Tweaking financial services? No, Open Banking will change society

As [Chris Michael](https://www.linkedin.com/in/cjemichael/) stated in his recent blog, Open Banking is going to be [awesome](https://www.linkedin.com/pulse/open-banking-awesome-chris-michael?articleId=6449732898202406912#comments-6449732898202406912&trk=prof-post) and as promised, we want to help the ecosystem by Open Sourcing the payment App we created during [ForgeRock](https://www.forgerock.com/) hackathon. Read the blog until the end to find the link to the code…

Imagine the ability of making a mobile payment [app](https://medium.com/yapily/building-a-payment-app-that-connects-to-open-banking-in-a-weekend-open-source-f24448d05488), that gives the user the ability to use his bank account in no time. And all of that just by asking the user’s permission to do so. No user credentials persistence, no need for backend infrastructure, no need to come up with a hacky approach. Just straight interaction between the user and the bank with a little help from Yapily.

It all starts with registering to the Yapily [dashboard](https://dashboard.yapily.com/register), creating your application and choosing the financial institutions that you want your user to interact with.

![head 1](//images.ctfassets.net/3ndxs7efitel/ize65LZOKexcsmGveLPKq/85aa835cf4a3dc0047d2a2d4b866322f/head_1.png)
![head 2](//images.ctfassets.net/3ndxs7efitel/GJLkNPrJQ6ZlmoBBrIhKg/da1db44c21f66c73932f67e14ed335c4/head_2.png)
![head 3](//images.ctfassets.net/3ndxs7efitel/1LZDgVGyFspMV8zZLVBse3/dd297d6444a711917f4a6caebf7017e4/head_3.png)

Once you are done, you will receive your Yapily credentials and you are ready to interact with the Yapily [API](https://docs.yapily.com/).

## Generating the SDK

Obviously based on your stack in order to interact with an API you need to implement each call using the programming language of your choice. That’s way too much effort, shouldn’t it be easier?

Of course it should be easier, that’s why we provide our API’s [Swagger](https://api.yapily.com/docs/swagger.json) specification. By providing our API’s Swagger specification you can generate the Yapily SDK with the language of you choice.

Cross platform application’s rock, thus [Flutter](https://flutter.io/) is a no brainer when it comes to mobile applications.

So let’s generate our SDK using the Swagger [codegen](https://swagger.io/tools/swagger-codegen/) tool.

    java -jar swagger-codegen-cli-2.3.0.jar generate -i  https://api.yapily.com/docs/swagger.json -l dart

## Configuring the Yapily SDK to your Flutter app

Now if you generate your own SDK it is up to you on how to distribute it and use it. For the [Dart](https://www.dartlang.org/) SDK we already did this for you by hosting it to our [github](https://github.com/yapily) profile, so no need to do anything whatsoever.

Supposing you already have a Flutter application up running all you need is to just include the Yapily SDK dependency at the pubspec.yaml file.
 
    dependencies:
      flutter:    
    sdk: flutter  
      yapily_sdk:    
    git:    
      url: git@github.com:yapily/yapily-sdk-dart.git    
      flutter_webview_plugin: '0.2.1+2'
  
## Use your Yapily application’s credentials
Now let’s put our Yapily credentials to our app. For the sake of this blog’s simplicity we are going to place them at the asset folder. Always be careful on how you distribute your credentials.

We will create a yapily-assets folder which shall contain the yapily-config.json file containing the the credentials of our Yapily app and some other configuration.

    {
     "key":"<your api key>",  
     "secret":"<your api secret>",  
     "userName": "moneyme_user",  
     "callback": "moneyme://whatever/"  
    }

Then specify the the yapily-assets folder in the assets section of the pubspec.yaml file.

    assets:  
    - graphics/  
    - yapily-assets/
    
Before proceeding to our application code we need to add a retrieval method for the Yapily config.

    import 'dart:convert' show json;  
    import 'dart:async';  
    import 'package:flutter/services.dart' show rootBundle;  
    
    class ConfigLoader {  
    
    static Future<YapilyConfig> loadAsync() {  
    return rootBundle.loadStructuredData<YapilyConfig>("yapily-assets/yapily-config.json",  
    (jsonStr) async {  
      final yapilyConfig = YapilyConfig.fromJson(json.decode(jsonStr));  
      return yapilyConfig;  
    });  
      }  
    }  
    
    class YapilyConfig {  
    
      final String key;  
      final String secret;  
      final String userName;  
      final String callback;  
      final String basePath;  
      
    YapilyConfig({this.key = "", this.secret = "", this.userName = "",   this.callback = "", this.basePath = ""});  
    
    factory YapilyConfig.fromJson(Map<String,dynamic> jsonMap) {  
    return new YapilyConfig(key: jsonMap["key"], secret: jsonMap["secret"],   userName: jsonMap["userName"], callback: jsonMap["callback"]);  
      }  
    } 

And that’s it! Now we are ready to add some open banking functionality backed by the Yapily SDK.

## Set up the Yapily client

First things first, let’s make a factory for our Yapily ApiClient

    import 'dart:async';  
    import 'yapily_config.dart';  
    import 'package:yapily_sdk/api.dart';  
    class ApiClientFactory {  
    static Future<ApiClient> create() {  
    return ConfigLoader.loadAsync().then( (yapilyConfig) {  
      var httpBasicAuth = HttpBasicAuth.setCredentials(username:   yapilyConfig.key, password: yapilyConfig.secret);  
      var apiClient = ApiClient.withAuth(httpBasicAuth);  
      return apiClient;  
    });  
      }  
    }

This factory will create a client eligible to issue requests upon the Yapily SDK.

Let’s create a Yapily user first. Our application’s config contains a username, so we are going to create a Yapily user and add a reference to that username.

In case the user already exists then we can just get his userUuid, which is needed to interact with the Yapily API.

    var apiClientFactory = ApiClientFactory.create();  
    apiClientFactory.then((apiClient) {  
      ApplicationUsersApi yapilyUsersApi = new ApplicationUsersApi(apiClient);  
      yapilyUsersApi.getUsersUsingGET().then((userList) {  
    userList.asMap().forEach((key, user) {  
      if (user.referenceId == yapilyConfig.userName) {  
    userUuid = user.uuid;  
      }  
    });  
    if (userUuid == null) {  
      //No user exists with this username  
      NewApplicationUser applicationUser = __new__ NewApplicationUser();  
      applicationUser.referenceId = yapilyConfig.userName;  
      yapilyUsersApi.addUserUsingPOST(applicationUser).then((yapilyUser) {  
    userUuid = yapilyUser.uuid;  
      });  
    }  
      });  
    });
    
## Get the user’s consent for a payment

Wouldn’t it be great if the user could just give his consent only for one payment and everything else like payment execution or payment completion being taken care of behind the scenes? That is what is so great with Open Banking and Yapily, they make things so simple.

We will ask the user to give his permission for a certain payment.

    var sortCodePaymentRequest = new SortCodePaymentRequest();  
    sortCodePaymentRequest.paymentReferenceId = new   Uuid().v4().toString().replaceAll("-", "");  
    sortCodePaymentRequest.senderAccountId = "9bd5ae68-2266-4dad-865b-4980550a72b7";  
    sortCodePaymentRequest.accountNumber = paymentData.accountNumber;  
    sortCodePaymentRequest.sortCode = paymentData.sortCode;  
    sortCodePaymentRequest.country = "GB";  
    sortCodePaymentRequest.currency = paymentData.currency;  
    sortCodePaymentRequest.name = paymentData.name;  
    sortCodePaymentRequest.reference = "moneyme payment";  
    .  
    .  
    .  
    var apiClientFactory = ApiClientFactory.create();  
      return apiClientFactory.then( (apiClient) {  
    return new   PaymentsApi(apiClient).createPaymentInitiationUsingPOST(id,paymentRequest:
    sortCodePaymentRequest, userUuid: userUuid, callback: callback);  
      }).then((apiResponse) {  
    //Open apiResponse.data.authUrl in a browser  
    });  

This will redirect the user to the institution of his choice in order to give consent for the payment.

![head 4](//images.ctfassets.net/3ndxs7efitel/5hE2V2mNJgDzvGc31JR0F9/4deb758649cb593588d0e35813aea48f/head_4.jpeg)
![head 5](//images.ctfassets.net/3ndxs7efitel/2iRxBl3nsAId7GsW1wcsuy/fbf9a46fe0575b06fb145cbe6601b42f/head_5.jpeg)
![head 6](//images.ctfassets.net/3ndxs7efitel/1MhXAkah6GzfKPRh1NkQTg/d0be0aed9a6811ec51e80d3f47acd945/head_6.jpeg)
*The user selects the bank and gives the consent for the payment*

## Execute the payment

What we just did is a crucial step that needs to be done before executing a payment request. First the user has to give his consent to you to execute a payment and then you can execute that payment using this consent. Eventually you shall be able to retrieve the user’s consent from the url passed back and thus executing the payment would be a walk in the park.

    var consentLookupString = 'consent=';  
    var consent = url.substring(  
    url.indexOf(consentLookupString) + consentLookupString.__length__, url.length);  
    var apiClientFactory = ApiClientFactory.create();  
    return apiClientFactory.then( (apiClient) {  
      return new PaymentsApi(apiClient).createPaymentUsingPOST(consent,   paymentRequest: sortCodePaymentRequest);  
    });

## Conclusion

You made it ! You just executed your first payment using Yapily and Open Banking. Back in the past you had to make the user to give his credentials, take full responsibility of them and ScreenScrap your way through it. Well not anymore! Who could imagine it could be so easy?

And as promised, you can find the source code on [github](https://github.com/yapily/yapily-demo-pisp-flutter).



Get a head start on building open banking applications using Flutter and Yapily

[Yapily](https://www.yapily.com/) developers participated to (and runner-ed? up) the [ForgeRock Hackathon](https://www.forgerock.com/about-us/press-releases/forgerock-hosts-its-first-ever-hackathon-dedicated-open-banking-ecosystem) last weekend! It was a great event and our congrats to the winning team, [IT Smart Systems](http://www.itsmartsystems.eu/), for their impressive payment request app. What both companies demonstrated is how fun and easy it will be to innovate in fintech with Open Banking going forward. Here, I’ll walk you through how in just 2 days we were able to demo a production quality app.

We knew we wanted to make a payment app that worked with [QR codes](https://en.wikipedia.org/wiki/QR_code). A couple of the scenarios that we imagined were:
1. QR codes for static payment requests (e.g. charity donations) to remove the need for typing in credit card details
2. Generating QR codes on your mobile device so you can chase debts immediately from your friends

Keeping in mind that QR codes are more secure than typing credit card details, the name of the game for us was __speed__. And thanks to our selection of tools, we achieved quite a lot in a short amount of time. Those tools that we would like to thank (in no particular order) are:

- [Flutter](https://flutter.io/) — a mobile development framework for building Android and iOS compatible apps
- [Firebase](https://firebase.google.com/) — a Google tool that provides backend functionality for web and mobile applications. We used this to handle image uploads but it offers a lot more
- [Yapily](https://www.yapily.com/) (of course) — our API that we used to obtain the login URL and authorise the payment for the [ForgeRock](https://www.forgerock.com/) test bank
- [ForgeRock sandbox](https://directory.ob.forgerock.financial/dashboard) — [ForgeRock](https://www.forgerock.com/) provided the mock bank for us to simulate user authentication, third party app authorisation and payments
- [Open Banking directory](https://directory.openbanking.org.uk/) — this is where entities must register in order to be able to connect to Open Banking APIs. It’s also worth noting that ForgeRock provides a testing directory as an alternative.

## MONEY ME — The app that makes payment requests easy

![building](//images.ctfassets.net/3ndxs7efitel/vkQkCdTsEU6RS1iY5XsMo/ff4bff4ec52485a3523bfb2627310a15/building.jpeg) ![building 3](//images.ctfassets.net/3ndxs7efitel/510mNbwTNgL4G0GPVIevqw/4b4d10dd9dd575d03a6a57949cfd88fc/building_3.jpeg) ![building 2](//images.ctfassets.net/3ndxs7efitel/3qki15rqtS6JrDMYFmqMN0/61296f552ba775643dbf4f72a155fd71/building_2.jpeg)
![building 4](//images.ctfassets.net/3ndxs7efitel/1Jo5ZbpmW51TCkdnflS0hj/637b26e43be03aff2bfbab5411fe62e1/building_4.jpeg) ![building 5](//images.ctfassets.net/3ndxs7efitel/69KchUGNaW1UVtHrXmvlhm/7feec632cd5c6768328afda1bd1310cf/building_5.jpeg)![building 6](//images.ctfassets.net/3ndxs7efitel/t5w1SepM354ARbmoPPYyw/122e0030b6aa934f694872b54f54ad31/building_6.jpeg) 
*The user selects his/her institution of choice and is directed to the bank website to authorise our payment app to execute this payment*

## Making the connection to ForgeRock.. and a bunch of other banks!
This part of the hack was done by creating an application in the [Yapily Dashboard.](https://dashboard.yapily.com/)

![building 7](//images.ctfassets.net/3ndxs7efitel/l6Ht6vQNAKzOk8sHlNKow/bcace85d4470e130333f87dd35772734/building_7.png)

Our application SSA (software statement assertion) registered in the [Open Banking directory](https://directory.openbanking.org.uk/) was used to sign our requests and create the authorisation url for the end user. And to leverage the power of our [Swagger](https://swagger.io/) documentation for the [Yapily API](https://api.yapily.com/docs/swagger.json), we generated a [Dart SDK](https://github.com/yapily/yapily-sdk-dart) to work with our Flutter app.

Details of our technical implementation to follow in another post ([here’s the code for now](https://github.com/yapily/yapily-demo-pisp-flutter)).

## However…

Making this connection was likely the most challenging aspect of connecting to the __ForgeRock sandbox bank__, largely due to the requirements of understanding the [Open Banking specification](https://openbanking.atlassian.net/wiki), generating the necessary signing and transport certificates, sharing and obtaining the relevant keys, knowing how to use the SSA’s and configuring your API client and the rest of your code to make properly-authorised requests.

Kudos to the teams that managed to get connected in that short time and the hackathon mentors for guiding the teams through the process.

## Connecting via Yapily

Each TPP ([third party provider](https://www.openbanking.org.uk/about-us/glossary/), aka the app connecting to the bank), even [connecting using Yapily](https://docs.yapily.com/), will still need to be registered in the [Open Banking directory](https://directory.openbanking.org.uk/). A key difference is that the usage of certificates, SSAs and the subsequent signing of API requests are handled by the [Yapily API](https://www.yapily.com/).

In our experience during the hackathon, even for a small prototype/hackathon project, some benefits became clear:

1. Quicker integrations to bank APIs
2. An app that is ready to connect to __multiple banks__

In a real application we would have seen even more benefits, including reducing the number of APIs to manage, response normalisation, various token management features, centralised analytics and monitoring.

## To conclude

It was a fun experience to use [Flutter](https://flutter.io/) to quickly build a nice clean mobile app; it was also great to use [Firebase](https://firebase.google.com/) for backend functionality without having to write code for a single controller, even if we didn’t get to play with the database; but the easiest part was connecting our mobile app to ForgeRock using our very own [Yapily API](https://www.yapily.com/)!



---



*Innovating in fintech just became so much easier! So what’s your idea? Get in touch at hello@yapily.com, we would love to help!*


---



And finally thanks to the rest of the Yapily team and the judges:

- [Will Beeson](https://www.linkedin.com/in/willbeeson/)
- [Chris Michael](https://www.linkedin.com/in/cjemichael/)
- [Megan Caywood](https://www.linkedin.com/in/megcaywood/)

the [ForgeRock](https://www.forgerock.com/) team:  

- Allan Foster
- Agnes Blach-Barth
- Hollie Dabson
- Ranjana Sharma
- Nick Caley
- Ben Jefferies
- Jamie Bowen
- Steve Ferris
- Fraser Wallace
- Quentin
- Wayne Blacklock
- Maxime Salnikov

volunteers:

- Julian Coombes
- Glyn Jackson

the [Raidiam](https://www.raidiam.com/) team:

- Barry O’Donohoe
- Ralph Bragg
- John Heaton-Armstrong
- Mark Haine

Disclaimer: This post is about a hackathon project. Any names used in this project, including Money Me, are in no way affiliated with any brand bearing the same or a similar name.

Building a payment app that connects to Open Banking in a weekend (open source)

However, we at Yapily are a curious bunch! 🤓 We are passionate problem solvers and focus on __How__ and __Why__ of the Open Banking. We believe

> Simplicity is the ultimate sophistication

and we are here to answer some of those nagging questions in simple words. So without much adieu, let us get started with Open Banking basics and what we do with simple questions and answers!

## So, What is Open Banking? English, please.
Open Banking is an initiative led by the UK Competition and Market Authority to push the 9 UK biggest banks to comply with the UK implementation of the Payment Service Directive 2. The directive is a consumer-focused regulatory change designed to open up competition in the European retail banking space (not just the UK!). Basically to make financial services __better__ 📈 and __cheaper__ 💸 for everyone. It will benefit everyone with a bank account (like me and you, who use bank accounts on a daily basis and small business owners who have current accounts with banks). The regulators in each of the 🇪🇺 European countries are asked to [make banks work harder for people](https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/544942/overview-of-the-banking-retail-market.pdf). Nowadays how, however, term Open Banking is used globally to refer to Open API in the banking space and this creates a bit of confusion…

## What do you mean by “making Banks work harder for people”?
By that we mean, banks 🏦 are asked to open up their channels to other players (who are called Third Party Providers — TPPs) and share customers data when requested.

## I mean, why should banks do that? Isn’t it bad for their business?
Because it is NOT banks data that is being requested, __*data rightfully*__ belongs to the customer and they have rights to share it with other providers at their discretion, in a secure & easy way. 🔐

## So, How can individual customers benefit from this open banking and bank data sharing?
The main benefit is that customers like you and me have more control over our bank data (not just one bank, but all our bank accounts!). We can now provide easy access to;

1. 💰Our favourite app that does budgeting for us,
2. ✔️Quickly verify our affordability for a mortgage with the lender, and
3. 🔎 Verify our identity using bank accounts, and much much more!

Also, most importantly __we now will know who has access to our data__, what is the access level (only accounts/ only payments/ duration of access) and ability to easily allow/ deny access to our banks. Want to know more, visit [www.openbanking.co.uk](http://www.openbanking.co.uk/) to see some of the regulated providers

## All sounds great! Now, how do various financial providers access this data?
This is where regulators have oversight over these financial providers and there are few regulatory and security measures to respect. For the 9 biggest UK banks, once that is done, the providers will have to be recognised by [Open Banking Implementation Entity (OBIE)](http://www.openbanking.co.uk/) in the UK 🇬🇧 as authorised TPPs.

Now, TPPs can get their users permission online and then banks and TPPs can share their users' data via secure digital communication channels called Application Programming Interfaces, in short — APIs. ⚙️

## What is this API? I’m lost again! 🧐

Simplistically, APIs are the machine to machine communication channels to access users data present in banks by these TPPs. Just like we are now reading this post in English, Imagine “ Mr Bank” as a person talking to another person “ Mr Financial Service Providers” in English over a radio. Just think this radio as API! When it comes to APIs, there are a set of agreed protocols and methodologies to be followed to successfully to get the communication, think of it like military communications with the set of instructions for the repeated set of actions!

## How to use the API technology to enable the benefits of open banking to end customers?
As mandated by the regulators, Banks needs to provide their own set of APIs to access and modify users data 📒 like account profile information, balances, transactions and also initiate payments 💳 on their behalf. Before banks provide access to data, very rightly so, the user needs to provide permission🔏 from their choice of Third Party Providers which is called access & consent token when it comes to computer communications.

## Very well, then what is the problem?
Each bank has a slightly different approach. For example, the way service provider signs up to them, to their users' authorisation flow to customer support and availability of banking systems to access this data. For this, service providers need to have the backend infrastructure setup and establish connectivity with each of the banks which would obviously take a lot of time, resources and money in setting up but also maintaining these connectivities. It is also worth noting that just in the UK, there are more than 300 banks and in Europe almost 5000!! 👀

Imagine setting up and maintaining connectivity with each of those banks to cater to your users.

## That to me sounds like a scalability and maintainability problem! What have you built to make things easier and enable open banking for financial providers?
You are absolutely right!🎯 We have focused on lifting this heavyweight backend infrastructure work while innovative fintech service providers can focus on their users and making banking better for them. Over the past few months, we have closely studied and witnessed the maturity of the 🇪🇺European Open Banking ecosystem as an insider to build a robust connectivity ecosystem to connect to banks. What we have built is an easy to use plug & play solution 🔌

## What do you mean by robust connectivity ecosystem and how does it help service providers?
We have built a single interface through which service providers can connect to banks via the API. Using our platform, service providers can easily create, configure and maintain all their bank connections. Instead of creating dedicated teams, spending upfront time and struggling to keep up with banks changes and downtime, service providers can easily integrate with us in few minutes and plug into all banks.🏦We enable companies to innovate and focus on their product, while we take care of the connectivity.

## So do you cater to all service providers?
We focus on the regulated service provider and we ensure they are authorised to access users data or make payments. We would never sit between our clients and their customers.

## After connecting, what can they do?
Once providers connect using our system, we have made it simple for service providers to manage their users' consent to access bank data from multiple banks.

After authorisation, service providers can receive data such as users accounts, account identity information, account transaction or make payments on their behalf.

## How is the data received any different from bank data?
Our API receives real-time raw data aggregated from various banks and normalises the user data so that it is cleaned and ready-to-use in service providers application.

## What about the security of customers data? 🔑
We put utmost importance on data security and especially when it comes to sensitive banking data. Hence, we don’t store/access user credentials and don’t store/access users data. Also when it comes to security, we have dedicated experts working on our infrastructure security and we are 🛡ISO 27001🛡 certified. We take data security very seriously!

## Who is your user? 👤 & What is the product you have built?
We focus on making the work of our client development teams easier and productive.

At the core, we offer development teams of service providers, a single powerful and RESTful Yapily API to connect to bank APIs. To manage connectivity, we provide a very easy to use app dashboard which helps connect to sandboxes and live banks plus built-in simulator to mimic bank connectivity before launching to production. We also provide very useful toolkits with each catering to specific needs of the developer such as API collection, software development kits, code examples, API docs, swagger and more. Visit [https://github.com/yapily ](https://github.com/yapily)for more info.

## Brilliant! How can my development team access your platform and get started? 🛠️
To get started with any API, developers typically look at API docs. We suggest you do the same. Visit [https://docs.yapily.com/#get-started](https://docs.yapily.com/#get-started) and it takes less than 5 mins to start making API calls. ⏰

## Lastly and more importantly, how many banks have you connected to? 🏦
Thought you’d never ask! We are currently connected to all the biggest banks and building societies in the UK🇬🇧 ([Open Banking entities](https://github.com/yapily/developer-resources/wiki/Open-Banking-UK)) which covers 90+% of the UK bank accounts. And, we offer connectivity to innovative challenger banks🚀 such as Revolut, Monzo, Starling and Tide. Together with UK banks, we have few international Bank APIs in our kitty — check out Nordea, BBVA, BNP, Hellenic & Deutsche Bank. In total, we have 35 banking entities connected, only via API!

We are very happy to have a chat with businesses looking to tap into Open Banking opportunity, learn about the needs and/or have a product demo. Feel free to reach out to us at 💬 [hello@yapily.com](mailto:hello@yapily.com).

We are eager to hear from you! 💙

Team Yapily

[www.yapily.com](https://www.yapily.com)

A Service Provider’s Guide to Open Banking

Learn more about open banking, explore use cases, and stay up-to-date on industry and company news...all in one place

Learn more about open banking, explore use cases, and be the first to hear about industry news and product updates. Free content in accessible formats. 

Payment Products

Data Products

Tools & Services

Industries

Technical Resources

Company

Insights

Yapily blog

Is your business sitting outside the ‘AIS perimeter’? 🤔

Tweaking financial services? No, Open Banking will change society

Get a head start on building open banking applications using Flutter and Yapily

Building a payment app that connects to Open Banking in a weekend (open source)

A Service Provider’s Guide to Open Banking