Version Control
Version | Date | Author | Comments |
|---|
| 2.0.0 | 29 Jun 2017 | Open Banking Open Data API Team | This is the baseline version. |
Overview
This specification includes all relevant artefacts for the Open Data ATM API Specification.
This endpoint can contain multiple brands owned by a particular banking group. Each brand can provide multiple ATMs.
An ATM consists of:-
- A unique Identification
- ATMServices - a pre-defined set of standard code names defining services available from an ATM e.g. PinUnblock
- OtherATMServices - allows a bank to add it's own non-standard/proprietary codes, code names & descriptions
- Accessibility - a pre-defined set of standard code names defining accessibility features that the ATM offers e.g. InductionLoop
- OtherAccessibility - allows a bank to add it's own non-standard/proprietary codes, code names & descriptions
- Supported Languages - the 2-digit ISO 639-1 language code
- Location - This is where the ATM is located and is a mix of a postal address and the geographic coordinates (decimal Latitude & Longitude). Postal address information can either be:-
i) Up to 7 lines of unstructured address information (AddressLine)
ii) Structured address information e.g. BuildingNumber, StreetName, Town, PostCode etc or a mixture of both.
Location is very important so the API provider should ensure that either geographical coordinates (preferred) or a combination of building number & postcode are supplied so that the ATM can be accurately located on a map. - Base currency - currently restricted to 'GBP' only, but may be extended in future to cope with other currencies dispensed by ATMs at airports, for example, if the API providers are able to supply this information
- Minimum possible amount - This will inform a consumer as the minimum possible amount that they can withdraw from an ATM. Note: This is not the same as the minimum denomination. For example, an ATM may dispense £5 notes but require the consumer to withdraw a minimum possible amount of £10.
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.
- Constraints Rulebook - set of rules which must be adhered to, dependent on the implementation scenario.
- Swagger - the API specification written using the Swagger API specification format.
Compliance Report
Message Implementation Guide