Version Control

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.