TL;DR

Here's a GraphQL schema generated from the UK Open Banking Account Information API: https://raw.githubusercontent.com/SensibleWood/open-banking-graphql/master/dist/account-info.graphql

Overview

I'd had an idea that the UK Open Banking API specifications could be transposed to a GraphQL specification. Why? Well, primarily to prove I could but really because of this from the GraphQL homepage:

Send a GraphQL query to your API and get exactly what you need, nothing more and nothing less.

Open Banking API specifications generally tend towards REST for good reasons, but having the GraphQL kind of granularity available for developers seems like a "good thing". So I started with the Account Information API, and this is the first drop.

Note: I am a freelancer at UK Open Banking and have worked on the project on-and-off for about 2 years. This is a private effort and not allied to Open Banking Limited.

Scope

I've only tackled Account Information so far - how Payment Initiation is dealt with needs more brain power than I have available at the moment (well maybe forever!). The source API specification (defined using Swagger) can be found here.

The approach I've taken is fairly pragmatic and I'm sure there are plenty of optimizations that could be achieved.

In brief:

Primitives in Swagger (JSON Schema really) map pretty well to their Scalar equivalent so most of these are just transposed.
Likewise for enum, but the Open Banking enums some need amending to compile in a GraphQL schema i.e. remove spaces, anything that's not [A-Za-z], then sort them nicely.
Where Swagger references a type and that type is a primitive it gets pulled directly into the parent. For example there is no AccountId interface, instead AccountId is always defined as String. This was done for pragmatism and simplicity in the resultant schema.
Any inline type declarations in the source Swagger are pulled into a type with a name comprised of the parent and child names concatenated with underscores. They quickly look hideous! However, it works for the time being until I refactor the approach (see Next Steps).

If you know the UK Open Banking standards it's pretty obvious what I don't deal with:

Consent is omitted as conceptually it straddles authorization and data - and I'm not sure this is something worth tackling at a first drop. With some more brains it might be dealt with...
Authentication/authorization is clearly outside the scope here and it's taken "as read' in this context i.e. the GraphQL query will be made by a client with appropriate entitlements on the data they are asking for.
The actual mapping for GraphQL query to REST calls at the backend will be done by Resolvers that I've yet to build (see Next Steps).

Next steps

Please see:

Issues list: https://github.com/SensibleWood/open-banking-graphql/issues or if you prefer...
Todo list (with the issues in...): https://github.com/SensibleWood/open-banking-graphql/projects/1

Building the schema

A copy of the Account Information schema is in dist but if you want to build it it's pretty straightforward really:

npm i
npm run build:account-info

This:

Generates the GraphQL schema
Lints it using the frankly bloody excellent Graph Schema Linter #props to @cjoudrey.

You can then take dist/account-info.graphql to your favorite GraphQL server and make hay.

Get Involved

Contributions are welcome - just get in touch.