< Back
Version 1.1

API Fundamentals

URI

All services exposed by the harmonised Mobile Money API use the following URI format:

{…]/{version}/mm/{Resource}

Where:

  • is defined upon implementation of the API by the API provider.

  • version is as per standards defined in the API Versioning section.

  • mm is literal for ‘Mobile Money’.

  • resource identifies the object and resource that is the subject of the API.

Methods

The API supports three types of request methods, each represented by a HTTP method as shown below:

  • POST. Used to create a resource for a given resource type. Transactions, Batch Transactions, Quotations, Bill Payments, Links, Authorisation Codes and Debit Mandates can be created.

  • PATCH. Used to update a resource for a given resource type. Batch Transactions, Links, Authorisation Codes and Debit Mandates can be updated. Note that only specific properties can be updated – refer to the relevant API for more information.

  • GET. Used to return a representation(s) of a resource(s) or a collection of resources. 

Patch Specifics

Updates to resources are accomplished by use of the HTTP PATCH method. The PATCH format is based upon IETF RFC 6902.  The replace operation is supported as per below:

Replace. This operation replaces the value of the target property with the supplied value. An example of a replace operation is [{ "op": "replace", "path": "/XYZ", "value": test }] where XYZ is the target property.

Resource Naming

The resource part of the URI path identifies the type of resource and if applicable, the specific resource for which an operation is to be performed. Resources are reflected in plural and by use of nouns. Primary resource types are as follows:

  • /transactions. Identifies a transaction resource.

  • /accounts. Identifies the financial resource that holds the funds. Examples include bank accounts and mobile wallets. 

  • /quotations. The resource that holds the quote or quotes for domestic and international remittance quotations.

  • /statemententries. The resource that returns an account statement representation. This is typically qualified by /accounts but can also be used to return a specific statement entry if the transaction reference is known.

  • /accounts/debitmandates. The resource that holds the debit mandate instruction(s), i.e. mandates that permit a Payee to deduct funds from a Payer’s account.

  • /accounts/links. Represents an account to account link between two systems. 

  • /accounts/authorisationcodes. Represents an authorisation code which pre-authorises a transaction.

  • /accounts/bills. Represents a bill that is due to be paid or has been paid.

  • /accounts/bills/payments. Represents the payment of a bill.

  • /accounts/accountname. Represents the primary account holders name.

  • /accounts/balance. Represents the balance(s) associated with an account.

  • /accounts/status. Represents the ability of the account to receive/send funds.

  • /batchtransactions. Represents a collection of transactions and related batch metadata.

    A more exhaustive list of permitted resources can be found in the detailed sections of this document.

     

Identifying the Resource

The harmonised Mobile Money API adopts a RESTful approach to identifying the resource on which an operation is to be performed. Where possible, the identifier is specified following the resource name in the path. In some cases, more than one identifier is required to identify the resource or there is a choice on which identifier to use. Therefore, flexibility has been built into the path to cater for these cases. This is illustrated in the following table.

Resource

Identifier

Identifier Placement

Transactions

Transaction Reference 

Path

Accounts

Various account identifiers (see Accounts for details)

Path

Mandates

Mandate Reference

Path

Quotations

Quotation Reference 

Path

Statement Entries

None if qualified by Accounts. If individual entry, then use Transaction Reference

Path

Links

Link Reference

Path

Bills

Account Identifiers

Path

Bill Payments

Bill Payment Reference and Account Identifiers

Path

Batch Transactions

Batch Reference

Path

Authorisation Codes

Authorisation Code

Path

Client Correlation ID

A Client Correlation ID can be supplied by the API client on HTTP POST and PATCH requests. The Client Correlation ID is a unique identifier that enables the client to correlate the API request with the resource created/updated by the provider. The client correlation ID is captured in the HTTP Header.

The format for the correlation ID is a UUID. Critically, the correlation ID supports safe operations. A POST request that is submitted with a correlation ID that has already been supplied will be rejected as unsafe, thus avoiding transaction duplication. 

Use Case Flow Patterns

All Use Cases supported by the API are built on standardised flow patterns. Flow patterns exist for viewing, creating and updating records (resources). Flow patterns can be combined in a single use case. For example, a domestic transfer may involve a name check on the recipient’s platform prior to a request to create a transaction. There are some simple rules to follow when using flow patterns. These are illustrated below:

  • Viewing. Only synchronous flows are supported for viewing resource(s). For example, a HTTP GET request to view balances must result in a HTTP response yielding the representation of the resource or the representation of the error. 

  • Creating/Updating. Synchronous and asynchronous flows are supported. A synchronous flow involves a definitive result consisting of the resource representation or error representation being returned in the GET, POST or PATCH response. An asynchronous flow is supported by two mechanisms – Call-back and Polling. These are described in more detail in the API Behavioural Model section.

Case Sensitivity

All API properties are defined in camelCase format.

All enumeration values referenced within the API use lower case notation – this includes acronyms and abbreviations. The only exceptions are for 

  • ISO Codes (country and currency) – the API uses these codes as defined per ISO. 

  • Error Codes. Upper Case is used to identify the first letter of each word to assist readability. 

HTTP Header Information

The following header information can be supplied for the mobile money API.

For the security headers, please also refer to the Mobile Money API Security Design for further information.

Standard Request Headers

Header

Value

Optionality

Notes

Accept

application/json

Mandatory

 

Accept-Charset

utf-8

Mandatory

 

Authorization

Authorization: Basic {base64Encode(concatenated client's username followed by ‘:’ and password)} OR OAuth2 Access Token. For OAuth2 format is {‘Bearer’ token value

Mandatory

 

Content-Length

Length of request content in 8-bit bytes

Mandatory

 

Content-Type

application/json

Mandatory

 

Standard Response Headers

Header

Value

Optionality

Notes

Content-Length

Length of response content 

Conditional

Applicable only if the HTTP response contains JSON body

Content-Type

application/json; charset=utf-8

Conditional

Applicable only if the HTTP response contains JSON body

Custom Request Headers

 

Header

Value

Optionality

Notes

X-API-Key

Used to pass pre-shared client's API key to the server

Conditional

Only required when API Client Authentication based on API key is used.

X-User-Bearer

Used to pass user's access token

Conditional

Only required when OAuth 2.0/OIDC authorisation framewrok is used for end-user authentication.

X-Date

{The date and time that the message was sent in HTTP-date format - RFC 7231}

Conditional

Used for Basic message integrity checks

X-Client-Id

Used to pass pre-shared client's identifier to the server

Conditional

Can be used in addition to X-API-Key.

X-Content-Hash

SHA-256 hex digest of the request content (encrypted or plain)

Conditional

Applicable only if the HTTP request contains JSON body and basic data integrity checking is to be performed.

X-CorrelationID

UUID

Conditional

Please refer to Client Correlation ID.

X-User-Credential-1

Contains an authentication credential of the end user (e.g. PIN, Password). 

Conditional

Should only be used when OAuth 2.0/OIDC authorisation framework has not been implemented by the API Provider.  

X-User-Credential-2

Contains an authentication credential of the end user (e.g. PIN, Password). Can be used when a second credential is required.

Conditional

Should only be used when OAuth 2.0/OIDC authorisation framework has not been implemented by the API Provider.  

X-Channel

string containing the channel that was used to originate the request. For example, USSD, Web, App..

Conditional

Used to identify the API invocation channel.

X-Callback-URL

string containing the URL which should receive the Callback for asynchronous requests.

Conditional

Will only be used by the API provider if they have implemented the Callback method.

X-Account-Holding-Institution-Identifier-Type

A header variable that identifies the type of the account holding institution. This header is used to support request routing and should be used in conjunction with the X-Account-Holding-Institution-Identifier header.

Optional

Supports three enum values:

  • lei

  • swiftbic

  • organisationid

If swiftbic or lei are specified, please ensure that the X-Account-Holding-Institution-Identifier contains a valid value for these types. 



 

X-Account-Holding-Institution-Identifier

A header variable that identifies the account holding institution. This header is used to support request routing and should be used in conjunction with the X-Account-Holding-Institution-Identifier-Type header.

Optional

When lei is supplied in X-Account-Holding-Institution-Identifier-Type, please refer to https://www.leiroc.org/lei.htm for permissible values.

When swiftbic is supplied in X-Account-Holding-Institution-Identifier-Type, please refer to https://www.swift.com/standards/data-standards/bic for permissible values.

Custom Response Headers

 

Header

Value

Optionality

Notes

X-Records-Available-Count

integer containing number of records that are available to be returned

Conditional

Used in the event of pagination

X-Records-Returned-Count

integer containing the number of records that have been returned

Conditional

Used in the event of pagination

X-Date

{The date and time that the response was sent in HTTP-date format - RFC 7231}

Conditional

Used for Basic message integrity checks

API Versioning

When changes are made to the Mobile Money API, a new version is released. There are three types of API versions:

  • major (backwards incompatible)

  • minor (backwards compatible)

  • patch (backwards compatible)

The following types of changes are considered to be backwards compatible:

  • Addition of new API Services.

  • Adding optional request properties and/or optional input parameters such as query strings to existing objects.

  • Addition of new properties to existing API responses.

  • Changing the order of properties within a request or response object.

  • New error codes.

The following types of changes are considered to be backwards incompatible and hence major:

  • Introducing mandatory properties.

  • Changing datatypes on properties.

  • Changes to API URIs/Paths.

The version that a client intends to use is indicated in the path. Format is ‘X.Y.Z’ where ‘X’ is the major version, ‘Y’ is the minor version and ‘Z’ is a patch version. Versions are sequentially numbered. When a major version is incremented, the minor version is reset to zero. 

The following table provides examples of API version compatibility:

Client Version

Provider Version

Compatible?

1.0.0

1.1.0

Yes

1.1.0

1.0.0

Client would need to submit only 1.0.0 related payload. If 1.1.0 services, properties or parameters are supplied by the client, the provider will reject the request.

2.0.0

1.0.0

No

1.0.0

2.0.0

No

Amount Validation

The mobile money API applies common validation to all amount properties. The following rules are applied during validation:

  • Between zero and four decimal places can be supplied.

  • Leading zeroes are not permitted except where the value is less than 1. For any value less than one, one and only one leading zero must be supplied.

  • Trailing zeroes are permitted.

  • Negative values are not permitted.

  • Maximum value that can be supplied is 999999999999999999.9999.

Amount validation examples are shown below.

Value

Permitted?

5

Yes

5.0

Yes

5.

No

5.00

Yes

5.5

Yes

5.50

Yes

5.5555

Yes

5.55555

No

555555555555555555

Yes

5555555555555555555

No

-5.5

No

0.5

Yes

.5

No

00.5

No

0

Yes

00.00

No

0.00

Yes

0000001.32

No

API Behaviour & Error Handling

The Mobile Money API manages API state and exception handling in a harmonised manner:

  • Harmonised API State Model. For synchronous requests, HTTP response codes are used exclusively to manage request state communication – both during the creation of a resource and the update of a resource. For asynchronous requests, a  RequestState object is additionally used to manage request state communication.

  • Harmonised HTTP Status Codes. Standardised HTTP status codes are associated with a harmonised state model for resource creation and update.

  • Harmonised Application-level Error Reason Codes. Standardised error codes are returned in a standardised error object for ALL client-responsible and server-responsible errors. Error parameters allow more detailed provider-specific diagnostic information to be returned with the error.

  • API Heartbeat enables API provider service availability to be established by clients on a regular basis.

  • The responses object enables clients to re-request a missing API response.

  • Error Handling Guidelines provide a standardised way of handling exceptions, including managing timeouts and retries.

Use of HTTP Response Codes

Response status is represented by the use of HTTP response codes. Figure 8.1 illustrates the valid response codes for synchronous requests. The response codes for asynchronous requests are represented by the sequence flows in the API Behavioural Model

 

Figure 2: Use of HTTP Response Codes for Synchronous Processing

API Behavioural Model

Overview

API behaviour is governed by the following factors:

  • The resource.

  • The type of operation, i.e. create, update or read.

  • Whether the provider will process the request synchronously.

  • Whether the provider implements callback or polling methods for asynchronous processing.

When combined, these factors drive API behaviour from the simplest request (e.g. view an account balance) to a more complex request (e.g. update a debit mandate asynchronously).

Request State Object

Asynchronous flows involve a callback or a polling mechanism to enable the client to determine the final state of the request. Both mechanisms involve the use of the RequestState object as per below:      

  • Callback. A request is initiated via a HTTP POST (create resource) or PATCH (update resource) request with an intermediate response represented by a RequestState object. Once the request has been completed, the provider will initiate a PUT request to the URL specified by the client in the X-Callback-URL request header. The callback will provide the client with one of the following:

    • Final representation of the resource for successful creation requests
    • A simple confirmation of update for successful update requests
  • Polling. Is initiated by a HTTP POST or PATCH request with an intermediate response provided in the form of the RequestState object. A HTTP GET is then issued on the RequestState by the client at regular defined intervals until the final resource state and resource reference is returned.

The object definition for RequestState is described below.

RequestState Object Properties

Name

Type

Description

 

Reference

Validation

serverCorrelationId

string

A unique identifier issued by the provider to enable the client to identify the RequestState resource on subsequent polling requests. 

🡪NA

🡨

 

UUID format

status

string

Indicates the status of the request.

🡪NA

🡨

 

Enumeration = pending, completed, failed

pendingReason

string

A textual description that can be provided to describe the reason for a pending status.

🡪NA

🡨O

   

notificationMethod

date-time

Indicates whether a callback will be issued or whether the client will need to poll.

🡪NA

🡨

 

Enumeration = callback, polling

objectReference

string

Provides a reference to the subject resource, e.g. transaction reference.

🡪NA

🡨

   

expiryTime

date-time

Indicates the time by which the provider will fail the request if completion criteria have not been met. For an example, a debit party failing to authorise within the allowed time period.

🡪NA

🡨O

   

pollLimit

integer

Indicates the number of poll attempts for the given requeststate resource that will be allowed by the provider.

🡪NA

🡨O

   

errorReference

object

If the asynchronous processing failed, details of the error will be returned here.

🡪NA

🡨O

Errors Object

 

API Sequence Flow Patterns

There are seven harmonised Mobile Money API sequence flows. These are reflected figure 3 and show the necessary HTTP methods, request object, response object and expected success and failure response codes for each API service. 




 

Figure 3 : Supported Mobile Money API Sequence Flow Patterns Matrix

API Sequence Flow Diagrams

Figures 4 to 10 illustrate the standard flow patterns for the Mobile Money API. The green flows represent a success path and red flows represent a failure path. A solid line indicates a HTTP request and a dotted line indicates a HTTP response.

 

Figure 4 : Read (GET) Flow Pattern

 

Figure 5 : Create (POST) Synchronous Flow Pattern

Figure 6 : Create (POST) Callback Asynchronous Flow Pattern


 

Figure 7 : Create (POST) Polling Asynchronous Flow Pattern

Figure 8 : Update (PATCH) Synchronous Flow Pattern

Figure 9 : Update (PATCH) Callback Asynchronous Flow Pattern


 

Figure 10 : Update (PATCH) Polling Asynchronous Flow Pattern

HTTP Status Responses and Error Categories

The following HTTP status codes are returned for the listed methods:

Method

Success

Intermediate*

Client Error

Server Error

GET

200

N/A

400, 401, 404

500, 503

PATCH

204

202

400, 401, 404

500, 503

POST

201

202

400, 401, 404

500, 503

*Note that ‘intermediate’ column in the table above relates to the HTTP response for the first leg of an asynchronous request.

Client Error Categories

Client errors fall into one of four categories as shown below:

Error Category

Description

HTTP Response Code

BusinessRule

The resource could not be successfully completed due a violation of a business rule. Business rules include financial limit violations, duplicate requests and invalid states.

400

Validation

Violation of a constraint that will prevent the resource from being processed. Examples include:

  • Invalid property length.

  • Failure to resolve regular expression.

400

Authorisation

It was not possible to authenticate or authorise the client or other party to perform the service.

401

Identification

The requested resource could not be matched on the system with the supplied identifier(s).

404

 

Additional non-harmonised 4xx HTTP response codes may be returned to the client by web or proxy servers.

Where the need for prevention of information leakage is paramount and this outweighs the benefits of error granularity, the provider may wish to use a 400 response code with no error body.

Server Error Categories

Server Errors are captured in two simple categories as per the following table:

Error Category

Description

HTTP Response Code

Internal

The request could not be completed due to non-client related issues that do not constitute complete system unavailability. Examples include software licence issues, unavailability of system configuration information. 

500

Service Unavailable

The service is not currently available. This could be due to network issues, issues with individual components or complete systems outages. Regardless of the cause, the result means that the request cannot be performed.

503

Additional non-harmonised 5xx HTTP response codes may be returned to the client by web or proxy servers.

Error Codes Definition

The mobile money API uses harmonised error codes in order to provide consistent error reporting back to API clients. Error codes are structured as per follows:

  • Error Category. All error codes must be associated with a client or server error category. This provides context and uniqueness to the error code.

  • Error Code. Provides the reason for the request failure. A human-readable description of the error is also available. Error codes are generally granular, i.e. they provide a specific reason for failure. In some cases, granularity is neither possible or desirable. Where this is the case, a ‘Generic’ code has been defined. Cases include:

    • The API Provider has generated an error that does not map to existing Rule error codes. 
    • The API Provider wishes to avoid disclosure of confidential information regarding the resource or parties to the resource. For example, the fact that a customer has breached their monthly transaction limit may not be disclosed to specific clients.
  • Error Parameters. Provides a construct to communicate supplementary information regarding the error in key/value pairs. The supplementary information is currently non-harmonised and can include:

    • The API provider-specific Error Code and Description.
    • Diagnostic information, e.g. affected subsystem, licence failure type etc…
    • Additional identification of the error subject, e.g. account identifiers, invalid properties etc…

Although error parameter contents are non-harmonised, care should be taken regarding confidentially of disclosed information. Confidential parameter information should only be disclosed to trusted clients.

A full list of harmonised Error Codes is provided here.

Errors Object Definition

All errors generated by the API provider will contain an Errors object in the response body. At a minimum, the Errors object must contain the Error Reason and Error Code. 

Errors Object Properties

Name

Type

Description

 

Reference

Validation

errorCategory

string

The category grouping for the error.

🡪M

🡨

 

Enumeration = Error Categories

errorCode

string

The harmonised error code identifying the reason for error.

🡪M

🡨

 

Enumeration = Error Reasons

errorDescription

string

A textual description of the error.

🡪O

🡨O

   

errorDateTime

date-time

The timestamp indicating when the error occurred.

🡪O

🡨

   

errorParameters

array

Diagnostic information in the form of key/value pairs relating to the error. 

🡪O

🡨

Metadata

 

API Heartbeat

The Heartbeat API is used for monitoring purposes and establishes whether the system of an API provider is in a state that enables a client to submit a request for processing within established SLAs. There are three states that can be returned by the API provider in response to a heartbeat request:

  • Available. The system is available and can receive and complete requests within SLAs.

  • Degraded. The system can receive and complete requests but not within SLAs, i.e. delay in transaction processing is anticipated. When known, the expected processing delay time can be returned by the provider.

  • Unavailable. The system cannot receive and process requests. Any submitted requests will fail whilst the system is in this state.

The Heartbeat can be requested using the following method and path:

  • GET /heartbeat 

Only synchronous API Heartbeat requests are supported. The HTTP response contains the following properties.


 

Heartbeat Response Properties

Name

Type

Description

 

Reference

Validation

serviceStatus

string

Provides the status of the requested service.

🡪NA

🡨

 

Enumeration = available, unavailable, degraded

delay

number

The anticipated processing delay in milliseconds.

🡪NA

🡨

 

serviceStatus property must be set to degraded.

plannedRestorationTime

date-time

Where the planned restoration time is known (e.g. scheduled maintenance), it can be provided in this property.

🡪NA

🡨O

   

Missing Response Retrieval

In some circumstances, the client may not have received the final representation of the resource for which it attempted to create or update. For example, a proxy server issue may have resulted in a HTTP 5xx response but the provider may have actually successfully completed the request. The /responses API allows a client to identify and retrieve the final representation of the resource assuming that the resource was created. In order to get a representation, the client issues a GET /Responses/{clientCorrelationId}. The provider will then match the client correlation ID to the appropriate resource and return a link to that resource. If the resource is not found for the given correlation ID then a HTTP 404 will be returned. 

The response object for /responses is detailed below.

Responses Properties

Name

Type

Description

 

Reference

Validation

link

string

Provides a URL to the resource associated with the given correlation ID.

🡪NA

🡨

   

Harmonised Error Codes

The error codes defined in this section are considered a basic initial set and will be expanded over time.

Error Category

Error Code

Error Code Description

BusinessRule

GenericError

A generic Error Code for the Rule Error Category. This is used in two scenarios:
1. The API Provider has generated an error that does not map to existing Rule error codes.
2. The API Provider wishes to avoid disclosure of confidential information regarding the resource or parties to the resource.

BusinessRule

DailyVolumeLimitExceeded

The party has exceeded their daily transacting volume limit - This can be a service limit or a limit that is specific to the party.

BusinessRule 

DailyValueLimitExceeded

The party has exceeded their daily transacting value limit - This can be a service limit or a limit that is specific to the party.

BusinessRule 

WeeklyVolumeLimitExceeded

The party has exceeded their weekly transacting volume limit - This can be a service limit or a limit that is specific to the party.

BusinessRule 

WeeklyValueLimitExceeded

The party has exceeded their weekly transacting value limit - This can be a service limit or a limit that is specific to the party.

BusinessRule 

MonthlyVolumeLimitExceeded

The party has exceeded their monthly transacting volume limit - This can be a service limit or a limit that is specific to the party.

BusinessRule 

MonthlyValueLimitExceeded

The party has exceeded their monthly transacting value limit - This can be a service limit or a limit that is specific to the party.

BusinessRule 

AccountMaxTotalValueExceeded

The party has exceeded their cumulative transacting value limit defined for the account.

BusinessRule 

AccountMaxTotalVolumeExceeded

The party has exceeded their cumulative transacting volume limit defined for the account.

BusinessRule 

LessThanTransactionMinValue

The amount specified for the transaction is less than the defined minimum for the service.

BusinessRule 

GreaterThanTransactionMaxValue

The amount specified for the transaction is greater than the defined maximum for the service.

BusinessRule 

MaxBalanceExceeded

The amount specified will cause the balance of the credit parties account to exceed the rule limit.

BusinessRule 

SamePartiesError

The debit and credit parties are the same.

BusinessRule 

DuplicateRequest

The request has previously been processed, i.e. this request is a duplicate and hence has been rejected.

BusinessRule 

InsufficientFunds

Available funds are not sufficient to enable the party to be debited for the requested transaction.

BusinessRule 

IncorrectState

The account is in a state that does not permit the requested service.

BusinessRule 

UnderPaymentNotAllowed

The requested amount is less than the amount that needs to be supplied for this transaction

BusinessRule 

OverPaymentNotAllowed

The requested amount is greater than the amount that needs to be supplied for this transaction

BusinessRule

RateLimitError

The client has submitted too many requests within a period of time.

BusinessRule

TransactionTypeError

The harmonised transaction type is not supported by the API Provider for the given request.

BusinessRule

NoMandateAuthority

The transaction request is not supported by the debit mandate.

BusinessRule

LinkViolation

The request has violated an account to account link for one of the following reasons:

  • Pull request not supported by the Link Mode.

  • Push request not supported by the Link Mode.

BusinessRule

CountryofOriginNotPermitted

The API Provider does not allow transactions to be accepted from the specified country of origin.

BusinessRule

NationalityNotPermitted

The API Provider does not allow transactions to be accepted from individuals with the specified nationality.

BusinessRule

IdDocumentNotSupported

The API Provider does not allow the specified ID Document.

BusinessRule

IssuingCountryNotSupported

The API Provider does not allow the issuing country of the specified ID document.

QuoteExpiry

QuoteHasExpired

A transaction with a quote reference cannot be processed at the quote has expired.

Identification

IdentifierError

The requested resource could not be matched on the system with the supplied identifier(s).

Validation

GenericError

A generic Error Code for the Validation Error Category. This is used in where the API Provider has generated an error that does not map to existing Validation error codes.

Validation

LengthError

The specified property contents are greater than the maximum allowed length or less than the minimum allowed length.

Validation

FormatError

The specified property contents do not conform to the format required for this Property.

Validation

NegativeValue

The amount supplied is negative and this is not allowed for the given service.

Validation

CurrencyNotSupported

The currency supplied is not supported by the API Provider.

Validation

MandatoryValueNotSupplied

A mandatory value has not been provided in the header and/or JSON body.

Validation

InvalidOffset

The pagination offset provided is not valid. This is typically because the offset is greater than the maximum number of records.

Authorisation

ClientAuthorisationError

General Client Authentication failure. No further details provided to prevent leakage of security information.

Authorisation

RequestDeclined

The debit party did not approve the request.

Authorisation

ServicingPartyAuthorisationError

The servicing party (e.g. agent) credentials or permissions are not valid.

Authorisation

RequestingPartyAuthorisationError

The party requesting the service has not provided the right credentials and/or does not have permission to perform this service.

Internal

GenericError

The request could not be completed due to a non-client related issues that do not constitute complete system unavailability. Examples include software licence issues, unavailability of system configuration information.

Service Unavailable

GenericError

The service is not currently available. This could be due to network issues, issues with individual components or complete systems outages. Regardless of the cause, the result means that the request cannot be performed.