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. |
| 2.2.0 | 26 Feb 2018 | Open Banking Open Data API Team | This release incorporates all known issues with 2.1.1 up to Feb 2018. 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
- Sort-Code(s) associated with branch
- 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.
Message Implementation Guide
Purpose
The message implementation guide (MIG) is designed to assist the implementers of the messaging specification by providing worked examples as to how the message fields should be completed in different scenarios.
The intention is that this will better ensure consistency. This guide should be read alongside the data dictionary which provides fuller information about the rules, constraints and guidelines that should be adhered to when populating the fields.
Format Notation
The format that we use in this document for field value assignment is:-
[] enclose a set of field values.
Where there are multiple records for a particular field, we depict this as [<record 1 value1>,< record 1 value2>…<recordn valuen>], whilst where we are showing that there is 1 field value in 1 record, and another field value in a 2nd record, I depict this as [<record1 value1>],[<record 2 value 1>],[<record 3 value 3>]
, seperates individual field values within a field value set.
“ surrounds a text or date field value.
Implementation Notes
Before implementing the message standard, it is very useful browsing current Branch Locator websites provided by your own organisation, in order to get a feel as to why you need to supply this information.
Branches v2.0 Top Level Design
Usage Examples
The Usage Examples are representative of different functional scenarios and are given in JSON format.
For simplicity, some of the mandatory JSON elements may be skipped to keep the size of the response manageable for this document, to highlight only on the relevant items. For example, when we are giving example of CreditInterest, then we might not show Overdraft and other json elements, to keep the JSON response size manageable.
Common Request for Usage Examples
GET /branches HTTP/1.1