Version Control

Version	Date	Author	Comments
2.0.0	18 Jul 2017	Open Banking Open Data API Team	This is the baseline version.
2.1.0	22 Aug 2017	Open Banking Open Data API Team	This release incorporates all known issues with 2.0.0 up to 18 Aug 2017. Please see the release notes for details.

Overview

This specification includes all relevant artefacts for the Open Data Branch API Specification.

This endpoint can contain multiple brands owned by a particular banking group. Each brand can own multiple branches.

A branch is made up of:-

Identification - unique identification for the branch
SequenceNumber - 0 indicates that this is a main branch, 1..n indicates that it's either a sub or mobile branch.
Name - the branch name
Type - Physical or Mobile
CustomerSegment - The segment of customers that the branch serves e.g. Private, Retail, Business
Photo - you can supply a URL showing an image of the branch e.g. use Google streetview
Service/Facilty (see subsection below)
Accessibility (see subsection below)
Postal Address (see subsection below)

Postal Address

This is where the Branch is located and is a mixture of a postal address and the geographic coordinates (decimal Latitude & Longitude). For geolocation purposes, it is highly recommended that each branch is identified via the geographic coordinates.

Mobile branch addresses

Mobile branch specific attributes such as parking location and stop name can be added as a 0..7 free format AddressLine fields

Services and Facilities/Other Services and Facilities

This allows the implementer to choose from standard services/facilities e.g. Parking and also allows the specification of other services/facilties using the OtherServiceFacility code block, where these are proprietary or currently missing from the standard code list. Periodic review of OtherServiceFacility information provided by each bank will allow us to decide if any of that information should be subsequently added to the standard code list.

Accessibility/Other Accessibility

This allows you to specify accessibility features of the branch e.g. Wheelchair access, and also allows specification of OtherAccessibility features, where these are proprietary or currently missing from the standard code list.

Availability

Deals with standard and non-standard e.g. seasonal opening days and times.

Specification

The following UML Class Diagram provides the hierarchical structure of the message in a graphical form, which is easier to digest.

Data Dictionary - provides detailed descriptions for each field in the message specification along with the associated code lists, constraints and other technical details such as cardinality, any pattern constraints, min, max length etc.
Swagger - the API specification written using the Swagger API specification format.

Compliance Report

Compliance Report - highlights changes made to fields & datatypes from v1.x.

Message Implementation Guide

Message Implementation Guide - provides worked examples of how to implement a particular message specification.