Gateway Technical Documentation

Access and Basics

How to start

Before starting the registration process your organisation must meet several prerequisites in order to be successfully onboarded as a customer for Coop Pank Gateway API:

• You must have a valid customer contract with Coop Pank.
• You must sign an additional Coop Pank Gateway contract.
• You must obtain an authentication certificate(s):
  • If you use the certificate for authentication issued by SK ID Solutions AS, you can use it for both Sandbox and Live. For operators it is mandatory to use the authentication certificate issued by SK ID Solutions AS. For single clients it is strongly suggested.
  • If you request the certificates from Coop Pank CA, you need test certificate for Sandbox and the other one for Live environment.

On-boarding process for starting to use live environment:

• The first thing you should do is submit the application for Coop Pank Gateway at Coop Pank webpage. In case you need any help with services, contact your personal Business Client Manager.
• Based on your application, IT support team prepares your dedicated Sandbox test environment.
• For testing in Sandbox an authentication certificate is needed. Sandbox accepts certificates issued by SK ID Solutions AS or by Coop Pank. Additional information about requesting an authentication certificate from Coop Pank.
• Development and testing of your integrations can start after receiving a confirmation email.
• After you are done with testing and ready to proceed to live, inform your Business Client Manager.
• In case you used the authentication certificate issued by Coop Pank for testing, you should request for another certificate for live environment. Live environment can not be used with test certificate. If you used the authentication certificate issued by SK ID Solutions AS, you can continue to use it for live as well.
• Business Client Manager prepares and signs the Coop Pank Gateway contract.
• After your contract is signed you will receive a confirmation email that your services are ready to use.

For additional help, please contact your personal Business Client Manager or the IT Support Team gateway@cooppank.ee.

Clients and connection schemes

It's possible to use the Gateway API services as a single client or as an operator.

Single clients

Using it as a single client means that client itself is the owner of the authentication certificate and connection software. Certificate provides access to one customer or legal entity only.

Operators/service providers and end users using their services

Operators or service providers are the intermediary. They themselves own a certificate and provide the service to multiple customers or legal entities. It is usually for accounting software providers and other similar business cases.

In this scheme there are two kinds of clients:

• service provider itself (software owner, technical aggregator) - they are directly connected to Gateway API;
• end user clients, who use Gateway API through service providers - not directly connected to Gateway API.

Only service provider connection software is using Gateway API services directly. End users are using the service provider software. For all requests we also need to know the end user - the actual client that uses the service provider. For this we require two HTTP headers in addition to regular expected input:

• Client-Code (registration code)
• Client-Country (country code in ISO 3166-1 alpha-2 format - issuing country of registration code)

If these are missing from the request, you will get a corresponding error.

Certificates

Authentication (connection) certificates are necessary for both test and live environments. Certificates are necessary for single clients and operators/service providers. Certificate identifies and confirms on transport layer that messages were sent by customer's software to the Bank.

• You can use the certificate for authentication issued by SK ID Solutions AS, you can use it for both Sandbox and Live. For operators it is mandatory to use the authentication certificate issued by SK ID Solutions AS. For single clients it is strongly suggested. There is no need to exchange any files with the bank and you can start using immediately.

• Alternatively you can request the certificates from Coop Pank CA, you need test certificate for Sandbox and the other one for Live environment. It is an SSL Base64 PEM certificate that also requires a key.

  Process for Coop Pank CA certificate generation (ignore if you are using SK ID Solution AS certificate):

  1. Follow the instructions to create the CSR file and private key.
  2. For Sandbox environment's certificate attach the CSR file when submitting the application for Coop Pank Gateway (CSR file does not have to be digitally signed).
  3. For Live environment's certificate send the CSR file to your personal Business Client Manager after you are done with testing. The CSR file must be digitally signed by the company's official representative (according to Estonian Business Registry).
  4. IT support team will sign it with CA certificate and will send you a generated certificate.

To verify your certificates and test the basic connection to the API you can use the Communication Test services service in both Live and Sandbox.

Environments

Gateway has two environments:

• Live environment
• Sandbox environment

Live

Live base URL is: https://cpgw.cooppank.ee/

Sandbox

Sandbox can be used to test your integrations when on-boarding or also any additional developments. It is technically also very similar to Live environment - the services, messages structure etc. is the same.

Sandbox base URL is: https://cpgw-sandbox.cooppank.ee/

Gateway API services

List of services which are available in the Gateway API.

Messaging

One of the main functions of Coop Pank Gateway is the messaging service. On the database side, it consists of  two tables - request table and response table. Customer posts its requests to request table and gets its messages from response table.  By default the response table returns oldest unread first. Messaging process consists of three steps: posting a request, getting the response and deleting the response.

Flow of API requests:

POST [base-url]/gateway/api/payment                  # initiate payment request
GET [base-url]/gateway/api/messages/next              # receive response message 
# handle message on customer side
DELETE [base-url]/gateway/api/messages/[Message-Response-Id]    # delete read message to confirm it's received
POST [base-url]/gateway/api/account-statement       # initiate account statement request
GET [base-url]/gateway/api/messages/next            # receive response message with account statement data status
# handle message on customer side
DELETE [base-url]/gateway/api/messages/[Message-Response-Id]    # delete read message to confirm it's received 
POST [base-url]/gateway/api/account-balance       # initiate account balance request
GET [base-url]/gateway/api/messages/next            # receive response message with account balance data status
# handle message on customer side
DELETE [base-url]/gateway/api/messages/[Message-Response-Id]    # delete read message to confirm it's received  
GET [base-url]/gateway/api/messages/next            # receive the oldest unread/undeleted message
# handle message on customer side
DELETE [base-url]/gateway/api/messages/[Message-Response-Id]    # delete read message to confirm it's received

Sending requests

POST [base-url]/gateway/api/payment
POST [base-url]/gateway/api/account-statement
POST [base-url]/gateway/api/account-balance

In response of successful sending of the request in HTTP header Message-Request-Id is returned, for example:

Message-Request-Id: 8743bd85-a917-4e12-9630-af8da25c4735

Every Message-Request-Id has at least one corresponding message-response-id. Some requests may have multiple - for example Payment Initiation.
Message-Request-Id: 8743bd85-a917-4e12-9630-af8da25c4735

Getting back the responses

For message traffic there are different possibilities. 

Get next message

GET [base-url]/gateway/api/messages/next

One can use the following filters and parameters. If no filters/parameters are selected, the oldest unread (undeleted) message is returned

• Filter-Response-Type - for example account statement, account_balance etc. It's useful if there are huge amount on unread messages. Then it makes easier to find the right one.
• Client-code - for using in Service Provide mode only. Company registration code of the Service Provider or its customer. When using the Service Provider own value also related customers messages are returned by default.
• Client-Country -  for using in Service Provide mode only. Issuing country of registration code (ISO country code, 2 char) 
• Filter-Service-Provider - for filtering operator's messages only when Client-Code and Client-Country are filled with operator's own values. Values: 1/true (filter is on) or 0/false (filter is off). For example possible combinations and their outcomes:
  • Client-Code and Client-Country are filled with operator's own values and Filter-Service-Provider=false, then the oldest unread message from the messages of the operator and its clients is returned.
  • Client-Code and Client-Country are filled with operator's own values and Filter-Service-Provider=true, then operator's own oldest unread message is returned.
  • Client-Code and Client-Country are filled with operator's own values, but filter is empty, then the oldest unread message from the messages of the operator and its clients is returned.
  • Client-Code and Client-Country are filled with operator's end user's value, then filter has no effect.

Headers of the response:

• Client-code - Client code of the company whose message is being returned.
• Client-Country -  Country code of the company whose message is being returned (ISO country code, 2 char).
• Message-Request-Id (optional) - the same id as the initial request. There are cases where request id can be missing, for example the Debit Credit Notification.
• Sample: Message-Request-Id: b84eee42-cb31-4687-8fad-2815ab3bd414 
• Message-Response-Id (mandatory) - unique response id.
  Sample: message-response-id: 886b106c-d62e-274b-9732-dc15e86c874e  
• Message-Response-Type - type of the response depending on the request or purpose. 
  Sample: message-response-type: PAYMENT_INITIATION  (response message for Payment Initiation request).

When executing the request you can receive following HTTP responses:

• 200 - there is at least one unread message and it is returned
• 204 - there are no unread messages

Get messages list

GET [base-url]/gateway/api/messages  

One can use the following filters and parameters. If no filters/parameters are selected, the list of messages in returned ordered by oldest unread (undeleted) message first and the default limit of messages is 10

• Filter-Response-Type - for example account statement, account_balance etc. It's useful if there are huge amount on unread messages. Then it makes easier to find the right one.
• Client-code - for using in Service Provide mode only. Company registration code of the Service Provider or its customer. When using the Service Provider own value also related customers messages are returned by default.
• Client-Country -  for using in Service Provide mode only. Issuing country of registration code (ISO country code, 2 char) 
• Limit - sets the maximum number of messages in the list (default is 10)

Headers of the response:

• Message-Request-Id (optional) - the same id as the initial request. There are cases where request id can be missing, for example the Debit Credit Notification.
  Sample: Message-Request-Id: b84eee42-cb31-4687-8fad-2815ab3bd414 
• Message-Response-Id (mandatory) - unique response id.
  Sample: message-response-id: 886b106c-d62e-274b-9732-dc15e86c874e  
• Message-Response-Type - type of the response depending on the request or purpose. 
  Sample: message-response-type: PAYMENT_INITIATION  (response message for Payment Initiation request).

When executing the request you can receive following HTTP responses:

• 200 - there is at least one unread message and it is returned
• 204 - there are no unread messages

List of messages is returned in JSon format:

• messageResponseId -  unique ID, for deleting the message, this ID must be referred
• messageRequestId -  unique ID. It matches the ID in the sending requests (payment, account stament, account balance)
• messageResponseType -  Refers to the service (account_statement, payment_initiation)
• clientCode -  client's reg.code 
• clientCountry -  client's country code
• messageCreatedTime -  timestamp

[
  {
    "messageResponseId": "886b106c-d62e-274b-9732-dc15e86c874e",
    "messageRequestId": "b84eee42-cb31-4687-8fad-2815ab3bd414",
    "messageResponseType": "PAYMENT_INITIATION",
    "clientCode": "12345678",
    "clientCountry": "EE",
    "messageCreatedTime": "2022-09-21T16:29:40.660"
  },
  {
    "messageResponseId": "590ab50c-6cd1-f742-8b75-d71eb054b377",
    "messageRequestId": "cd0b349b-dec5-4878-8718-60f3f02c6067",
    "messageResponseType": "ACCOUNT_STATEMENT",
    "clientCode": "12345678",
    "clientCountry": "EE",
    "messageCreatedTime": "2022-09-22T08:58:40.114"
  }
]

Read the content of the message

GET [base-url]/gateway/api/messages/{messageResponseId}   

 To read the content of the message, use this service. MessageResponseId is the same that is returned by the service [base-url]/gateway/api/messages.

When executing the request you can receive following HTTP responses:

• 200 - there is at least one unread message and it is returned
• 204 - there are no unread messages
• 404 - no message found with given message response id

Get number of unread (undeleted) messages

GET [base-url]/gateway/api/messages/count

Use this service to get the number of pending messages.

Sample response:

{
    "count": 8
}

Deleting the message = Confirm the successful reading of the message/response

After reading a message it should be deleted promptly, it's so called confirming the reading. For this, use the response id.

DELETE [base-url]/gateway/api/messages/{messageResponseId}

Bulk delete = bulk delete

For deleting the messages there's another option where one can delete multiple messages at a time. This is more useful when used together with List of Messages service. 

POST [base-url]/gateway/api/messages/delete

Sample body in JSon format:

{
  "messageResponseIds": [
    "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "886b106c-d62e-274b-9732-dc15e86c874e"
  ]
} 

Response body contains the results for all the requests messages.

• status: 200 - delete successful; 400 - already deleted or not found

Response sample:

{
  "messages": [
    {
      "messageResponseId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
      "status": 400
    },
    {
      "messageResponseId": "886b106c-d62e-274b-9732-dc15e86c874e",
      "status": 200
    }
  ]
}

Dates and time-zones

Depending on the season GMT+2 or GMT+3 time zone is used in Estonia. By default all date and time data uses that.

Precise information is available: https://www.timeanddate.com/time/zone/estonia/tallinn

Request's dates

Dates that are specified in requests (for example Account Statement, Account Balance, Payment Initiation) use ISO date format. Only following form "YYYY-MM-DD" is taken into account and all other additions are ignored (for example time zones).

Used format is "YYYY-MM-DD" where:

• YYYY indicates the year
• MM indicates the month
• DD indicates the day

Language and Code Pages

We use the Windows-1257 code page with mainly supporting Baltic and a list of other European languages. ISO20022 standard messages use UTF-8.

UTF-8 Unicode characters, which are not supported by Windows-1257, will be replaced with "?" symbols. This rule applies to all API services unless stated differently.

For example unstructured payment description submitted in the payment file:

//Submitted by customer
Payment description - личный.
 
//Sent to the payment scheme
Payment description - ????????.

Error handling

Service specific errors are returned with following XML file. Errors are mostly returned with descriptions.

Sample

<?xml version='1.0' encoding='UTF-8'?>
  <Errors>
    <Error>
      <ErrorCode>errStatement_RequestInvalid</ErrorCode>
      <Description>Request message fails xsd validation</Description>
      <Field/>
    </Error>
  </Errors>

Response codes

Communication Test

Heartbeat service

GET [base-url]/heartbeat

With heartbeat it's possible to test if system is up and connection certificate is configured correctly. If configured correctly, it returns current system time.
One should use for testing some API testing tool (Postman, SOAP UI, cURL). Sample statements is in code box below. Your PEM certificate should be put instead yourcert.crt and yourkey.key should be replaced with key files. If you have certificate with password, you should add password in the curl command after certificate's name yourcert.crt:password

// Sandbox:
curl -X GET "https://cpgw-sandbox.cooppank.ee/gateway/api/heartbeat" --cert yourcert.crt --key yourkey.key
 
// Live:
curl -X GET "https://cpgw.cooppank.ee/gateway/api/heartbeat" --cert yourcert.crt --key yourkey.key
 
// Sandbox - for service providers:
curl -X GET "https://cpgw-sandbox.cooppank.ee/gateway/api/heartbeat" --cert yourcert.crt --key yourkey.key -H "Client-Code: 012345678" -H "Client-Country: EE"
 
// Live - for service providers:
curl -X GET "https://cpgw.cooppank.ee/gateway/api/heartbeat" --cert yourcert.crt --key yourkey.key -H "Client-Code: 012345678" -H "Client-Country: EE"

Sample response

<HeartBeatResponse>
  <TimeStamp>2022-08-19T15:06:07.141</TimeStamp>
  <AuthorizedUser/>
  <UserRequest/>
</HeartBeatResponse>

GET [base-url]/heartbeat/mq

It's the same as GET /heartbeat, but the response message will be created in the queue and could be read with GET/messagest/next. Response includes additional user information. This service can be used for simulating the general messaging logic without more complex Account Information or Payments requests.

Sample response

<?xml version='1.0' encoding='UTF-8'?>
  <HeartBeatResponse>
    <TimeStamp>2022-08-22T13:22:00.007</TimeStamp>
    <AuthorizedUser>
      <Name>Test user</Name>
      <Code>12345678</Code>
    </AuthorizedUser>
    <UserRequest><Content>test</Content></UserRequest>
  </HeartBeatResponse>

POST [base-url]/heartbeat

This service can be used for testing the ASICE and BDOC requests.

Request must contain digitally signed request.xml file, saved in ASICE or BDOC. Service takes authenticated user info, extracts ASICE or BDOC signature data and request.xml content and creates response xml like shown below.

One can read the response via messaging service GET "https://cpgw-sandbox.cooppank.ee/gateway/api/messages/next".

Sample response

<?xml version='1.0' encoding='UTF-8'?>
  <HeartBeatResponse>
    <TimeStamp>2022-08-22T13:34:25.007</TimeStamp>
    <AuthorizedUser>
      <Name>Test user</Name>
      <Code>12345678</Code>
    </AuthorizedUser>
    <Signatures>
      <Signature>
        <Name>Coop Pank</Name>
        <Code>12345678</Code>
      </Signature>
    </Signatures>
    <UserRequest><xml></UserRequest>
  </HeartBeatResponse>

Request Account Report

Account Statement

POST [base-url]/account-statement

Account Statement is used when statement end-date is in the past and it is used to report booked transactions and balances.
With Account Statement one receive the list of transactions, both incoming and outgoing, also payments with added details. Request can be made for the given period for one Customer Account.
For this endpoint the max amount of requests per hour apply - max 10 requests in an hour per every client (not per account).

Account Balance

POST [base-url]/account-balance

Account Balance is used for current day statement and it reports intraday transactions and balances (actual and free balance for all the currencies used). Balances are provided real-time on the moment of generating the response. Request can be made for one Customer Account at once.
To request Payment limits info, one can use optional Prtry parameter. Both total and free limits for Daily and Monthly periods are received.
For this endpoint the max amount of requests per hour apply - max 10 requests in an hour per every client (not per account).

XML format (camt.060.001.06)

This description is related to the ISO 20022 Account Report Request camt.060.001.06 XML-based description, which will replace the proprietary electronic account reporting standards used by banks operating in Estonia. One can use it for both Account Statement and Account Balance requests.

The AccountReportingRequest message is sent by the account owner, either directly or through a forwarding agent, to one of its account servicing institutions. It is used to ask the account servicing institution to send a report on the account owner's account in a BankToCustomerAccountReport.
Some values apply for both services and some are specific to either Statements or Balances response only. 

Request's Content-Type has to be 'multipart/form-data' and it has to contain XML file in "request" position, with its type also defined as "text/xml".

Example how to create Account Statement Request with Java Apache HttpClient

String xml = "<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.060.001.06">
    <AcctRptgReq>
        <GrpHdr>
            <MsgId>20230201171147610</MsgId>
            <CreDtTm>2023-01-02T17:11:47.610+02:00</CreDtTm>
        </GrpHdr>
        <RptgReq>
            <Id>20230201171147610</Id>
            <ReqdMsgNmId>camt.053.001.02</ReqdMsgNmId>
            <Acct>
                <Id>
                    <IBAN>EE214204200000000000</IBAN>
                </Id>
            </Acct>
            <AcctOwnr>
                <Pty/>
            </AcctOwnr>
            <RptgPrd>
                <FrToDt>
                    <FrDt>2023-01-01</FrDt>
                    <ToDt>2023-01-01</ToDt>
                </FrToDt>
                <Tp>ALLL</Tp>
            </RptgPrd>
        </RptgReq>
    </AcctRptgReq>
</Document>";
 
try (CloseableHttpClient client = HttpClients.createDefault()) {
    HttpPost request = new HttpPost(gatewayUri + "/account-statement");
    request.setEntity(MultipartEntityBuilder.create()
        .addBinaryBody("request", xml.getBytes(), ContentType.create("text/xml"), "request")
        .setLaxMode()
        .build());
 
    client.execute(request);
} catch (IOException ex) {
    ...
}

Message root

Group header

Samples

Account Statement

This is sample request for the account statement for account EE214204200000000000.

Parameters used

• The period: 31th of August 2022, time.

<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.060.001.06">
    <AcctRptgReq>
        <GrpHdr>
            <MsgId>MSGIDCOOPPANKTEST01</MsgId>
            <CreDtTm>2022-08-31T16:15:07.617</CreDtTm>
        </GrpHdr>
        <RptgReq>
            <ReqdMsgNmId>camt.053.001.02</ReqdMsgNmId>
            <Acct>
                <Id>
                    <IBAN>EE214204200000000000</IBAN>
                </Id>
            </Acct>
            <AcctOwnr>
                <Pty />
            </AcctOwnr>
            <RptgPrd>
                <FrToDt>
                    <FrDt>2022-08-31</FrDt>
                    <ToDt>2022-08-31</ToDt>
                </FrToDt>
                <Tp>ALLL</Tp>
            </RptgPrd>
            <ReqdBalTp>
                <CdOrPrtry>
                    <Prtry>DATE</Prtry>
                </CdOrPrtry>
            </ReqdBalTp>
        </RptgReq>
    </AcctRptgReq>
</Document>

Account Balance

This is sample request for the account statement for account EE214204200000000000

Parameters used

• Balances are taken from current date, therefore it's not necessary to use Date parameters 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.060.001.06">
    <AcctRptgReq>
        <GrpHdr>
            <MsgId>MSGIDCOOPPANKTEST01</MsgId>
            <CreDtTm>2022-08-30T16:15:07.617</CreDtTm>
        </GrpHdr>
        <RptgReq>
            <ReqdMsgNmId>camt.053.001.02</ReqdMsgNmId>
            <Acct>
                <Id>
                    <IBAN>EE214204200000000000</IBAN>
                </Id>
            </Acct>
            <AcctOwnr>
                <Pty/>
            </AcctOwnr>
            <RptgPrd>
                <FrToDt>
                    <FrDt>2022-08-30</FrDt>
                    <ToDt>2022-08-30</ToDt>
                </FrToDt>
                <Tp>ALLL</Tp>
            </RptgPrd>
        </RptgReq>
    </AcctRptgReq>
</Document>

Error codes

Response Account Balance

XML format (ISO 20022 Account Report Message camt.052.001.06)

The ISO 20022 Account Report Message camt.052.001.06 is used for current day balances. Two balances are returned: the actual booked balance without reservations and the actual available balance with reservations. If the current balance is 0 EUR, then it's returned so.

Rate limit - max amount of requests is 10 per hour for each client (not per account).

Header Message-Response-Type: ACCOUNT_BALANCE

Message structure

Group Header - mandatory, occurs once.
Report - mandatory and repetitive per currency. Includes one to many Balance blocks.

Message root

Group header

Report

Sample

Sample account EE214204200000000000 has two balances in EUR (current available and current booked balance). 

<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.052.001.02" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:camt.052.001.02 camt.052.001.02.xsd">
  <BkToCstmrAcctRpt>
    <GrpHdr>
      <MsgId>STMMSGID/20220922124310_892323</MsgId>
      <CreDtTm>2022-09-22T12:43:10.209+03:00</CreDtTm>
    </GrpHdr>
    <Rpt>
      <Id>EE214204200000000000EUR20220922</Id>
      <CreDtTm>2022-09-22T12:43:10.209+03:00</CreDtTm>
      <FrToDt>
        <FrDtTm>2022-09-22T12:43:10.209+03:00</FrDtTm>
        <ToDtTm>2022-09-22T12:43:10.209+03:00</ToDtTm>
      </FrToDt>
      <Acct>
        <Id>
          <IBAN>EE214204200000000000</IBAN>
        </Id>
        <Ccy>EUR</Ccy>
      </Acct>
      <Bal>
        <Tp>
          <CdOrPrtry>
            <Cd>ITBD</Cd>
          </CdOrPrtry>
        </Tp>
        <Amt Ccy="EUR">991946579.49</Amt>
        <CdtDbtInd>CRDT</CdtDbtInd>
        <Dt>
          <Dt>2022-09-22</Dt>
        </Dt>
      </Bal>
      <Bal>
        <Tp>
          <CdOrPrtry>
            <Cd>ITAV</Cd>
          </CdOrPrtry>
        </Tp>
        <Amt Ccy="EUR">991949579.49</Amt>
        <CdtDbtInd>CRDT</CdtDbtInd>
        <Dt>
          <Dt>2022-09-22</Dt>
        </Dt>
      </Bal>
    </Rpt>
  </BkToCstmrAcctRpt>
</Document>

Response Account Statement

XML format (ISO 20022 Account Statement Message camt.053.001.02)

CAMT.053.001.02 is used when statement end-date is in the past and it is used to report booked transactions and balances. Information about the opening balance, the closing balance, and the available balance with all booked transactions of a specified period is included in the message. 
It's possible to make a request up to 7 years and 5 days old data.

Header Message-Response-Type: ACCOUNT_STATEMENT

Message structure

Group Header – mandatory, presented once.  
Statement – mandatory and repetitive. It should be repeated for each account on which a statement is provided. 
Balance – mandatory and repetitive. Contains elements such as Opening Booked Balance and Closing Booked Balance.
Entry – included in the Statement block. Contains information related to an entry on the account.
Entry Details – included in the Entry block. Contains detailed information related to the entry.

Message root

Group header

Statement

Sample

<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.02" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:camt.053.001.02 camt.053.001.02.xsd">
  <BkToCstmrStmt>
    <GrpHdr>
      <MsgId>MSGID_20220922113510_628688</MsgId>
      <CreDtTm>2022-09-22T11:35:10.231+03:00</CreDtTm>
      <MsgPgntn>
        <PgNb>1</PgNb>
        <LastPgInd>true</LastPgInd>
      </MsgPgntn>
    </GrpHdr>
<Stmt xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.02">
  <Id>EE214204200000000000EUR20220922</Id>
  <ElctrncSeqNb>1</ElctrncSeqNb>
  <CreDtTm>2022-09-22T11:35:10.231+03:00</CreDtTm>
  <FrToDt>
    <FrDtTm>2022-08-01T00:00:00.000+03:00</FrDtTm>
    <ToDtTm>2022-08-30T23:59:59.000+03:00</ToDtTm>
  </FrToDt>
  <Acct>
    <Id>
      <IBAN>EE214204200000000000</IBAN>
    </Id>
    <Ccy>EUR</Ccy>
    <Ownr>
      <Nm>TEST OÜ</Nm>
      <Id>
        <OrgId>
          <Othr>
            <Id>1111111</Id>
          </Othr>
        </OrgId>
      </Id>
    </Ownr>
    <Svcr>
      <FinInstnId>
        <BIC>EKRDEE22</BIC>
        <Nm>COOP PANK AS</Nm>
        <PstlAdr>
          <AdrTp>BIZZ</AdrTp>
          <StrtNm>Maakri</StrtNm>
          <BldgNb>30</BldgNb>
          <PstCd>15014</PstCd>
          <TwnNm>Tallinn</TwnNm>
          <CtrySubDvsn>Harjumaa</CtrySubDvsn>
          <Ctry>EE</Ctry>
        </PstlAdr>
      </FinInstnId>
    </Svcr>
  </Acct>
  <Bal>
    <Tp>
      <CdOrPrtry>
        <Cd>OPBD</Cd>
      </CdOrPrtry>
    </Tp>
    <Amt Ccy="EUR">993946639.49</Amt>
    <CdtDbtInd>CRDT</CdtDbtInd>
    <Dt>
      <Dt>2022-08-01</Dt>
    </Dt>
  </Bal>
  <Bal>
    <Tp>
      <CdOrPrtry>
        <Cd>CLBD</Cd>
      </CdOrPrtry>
    </Tp>
    <Amt Ccy="EUR">993946629.49</Amt>
    <CdtDbtInd>CRDT</CdtDbtInd>
    <Dt>
      <Dt>2022-08-30</Dt>
    </Dt>
  </Bal>
<TxsSummry xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.02">
  <TtlCdtNtries>
    <NbOfNtries>0</NbOfNtries>
    <Sum>0.00</Sum>
  </TtlCdtNtries>
  <TtlDbtNtries>
    <NbOfNtries>2</NbOfNtries>
    <Sum>10.00</Sum>
  </TtlDbtNtries>
</TxsSummry>
<Ntry xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.02">
  <NtryRef>1</NtryRef>
  <Amt Ccy="EUR">5.00</Amt>
  <CdtDbtInd>DBIT</CdtDbtInd>
  <Sts>BOOK</Sts>
  <BookgDt>
    <Dt>2022-08-26</Dt>
  </BookgDt>
  <ValDt>
    <Dt>2022-08-26</Dt>
  </ValDt>
  <AcctSvcrRef>717CC1F</AcctSvcrRef>
  <BkTxCd>
    <Domn>
      <Cd>PMNT</Cd>
      <Fmly>
        <Cd>ICDT</Cd>
        <SubFmlyCd>BOOK</SubFmlyCd>
      </Fmly>
    </Domn>
  </BkTxCd>
  <NtryDtls>
    <TxDtls>
      <Refs>
        <AcctSvcrRef>717CC1F</AcctSvcrRef>
        <InstrId>84</InstrId>
        <TxId>717CC1F</TxId>
      </Refs>
      <AmtDtls>
        <TxAmt>
          <Amt Ccy="EUR">5.00</Amt>
        </TxAmt>
      </AmtDtls>
      <RltdPties>
        <Dbtr>
          <Id>
            <OrgId>
              <Othr>
                <Id>123412</Id>
                <SchmeNm>
                  <Prtry>COID</Prtry>
                </SchmeNm>
              </Othr>
            </OrgId>
          </Id>
        </Dbtr>
        <Cdtr>
          <Nm>Mari Tamm</Nm>
          <Id>
            <PrvtId>
              <Othr>
                <Id>48603106511</Id>
              </Othr>
            </PrvtId>
          </Id>
        </Cdtr>
        <CdtrAcct>
          <Id>
            <IBAN>EE584204200000000013</IBAN>
          </Id>
        </CdtrAcct>
      </RltdPties>
      <RltdAgts>
        <CdtrAgt>
          <FinInstnId>
            <BIC>EKRDEE22</BIC>
            <Nm>COOP PANK</Nm>
          </FinInstnId>
        </CdtrAgt>
      </RltdAgts>
      <RmtInf>
        <Ustrd>testimiseks</Ustrd>
      </RmtInf>
    </TxDtls>
  </NtryDtls>
</Ntry>
<Ntry xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.02">
  <NtryRef>2</NtryRef>
  <Amt Ccy="EUR">5.00</Amt>
  <CdtDbtInd>DBIT</CdtDbtInd>
  <Sts>BOOK</Sts>
  <BookgDt>
    <Dt>2022-08-26</Dt>
  </BookgDt>
  <ValDt>
    <Dt>2022-08-26</Dt>
  </ValDt>
  <AcctSvcrRef>717CC26</AcctSvcrRef>
  <BkTxCd>
    <Domn>
      <Cd>PMNT</Cd>
      <Fmly>
        <Cd>ICDT</Cd>
        <SubFmlyCd>BOOK</SubFmlyCd>
      </Fmly>
    </Domn>
  </BkTxCd>
  <NtryDtls>
    <TxDtls>
      <Refs>
        <AcctSvcrRef>717CC26</AcctSvcrRef>
        <InstrId>85</InstrId>
        <TxId>717CC26</TxId>
      </Refs>
      <AmtDtls>
        <TxAmt>
          <Amt Ccy="EUR">5.00</Amt>
        </TxAmt>
      </AmtDtls>
      <RltdPties>
        <Dbtr>
          <Id>
            <OrgId>
              <Othr>
                <Id>123412</Id>
                <SchmeNm>
                  <Prtry>COID</Prtry>
                </SchmeNm>
              </Othr>
            </OrgId>
          </Id>
        </Dbtr>
        <Cdtr>
          <Nm>Mari Tamm</Nm>
          <Id>
            <PrvtId>
              <Othr>
                <Id>48603106511</Id>
              </Othr>
            </PrvtId>
          </Id>
        </Cdtr>
        <CdtrAcct>
          <Id>
            <IBAN>EE584204200000000013</IBAN>
          </Id>
        </CdtrAcct>
      </RltdPties>
      <RltdAgts>
        <CdtrAgt>
          <FinInstnId>
            <BIC>EKRDEE22</BIC>
            <Nm>COOP PANK</Nm>
          </FinInstnId>
        </CdtrAgt>
      </RltdAgts>
      <RmtInf>
        <Ustrd>testimiseks</Ustrd>
      </RmtInf>
    </TxDtls>
  </NtryDtls>
</Ntry>
</Stmt>
</BkToCstmrStmt>
</Document>

For long account statements containing larger number of transactions pagination can be used - one Account Statement response receives more than one response in the queue. Currently the pagination limit per message is 10 000 transactions. Total amount of transactions in any response is 100 000 - in 10 separate response messages. Layout of first message header:

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.02" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:camt.053.001.02 camt.053.001.02.xsd">
  <BkToCstmrStmt>
    <GrpHdr>
      <MsgId>MSGID_20220922113510_628688</MsgId>
      <CreDtTm>2022-09-22T11:35:10.231+03:00</CreDtTm>
      <MsgPgntn>
        <PgNb>1</PgNb>
        <LastPgInd>false</LastPgInd>
      </MsgPgntn>
    </GrpHdr>    
     ...

Layout of second and final message header:

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.02" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:camt.053.001.02 camt.053.001.02.xsd">
  <BkToCstmrStmt>
    <GrpHdr>
      <MsgId>MSGID_20220922113510_628688</MsgId>
      <CreDtTm>2022-09-22T11:35:10.231+03:00</CreDtTm>
      <MsgPgntn>
        <PgNb>2</PgNb>
        <LastPgInd>true</LastPgInd>
      </MsgPgntn>
    </GrpHdr>
     ...

Debit Credit Notification

XML format (ISO 20022 Bank To Customer Debit Credit Notification camt.054.001.02)

CAMT.054.001.02 Bank To Customer Debit Credit Notification is used to report single booked entry. The customer can recieve either debit or credit notifications or both, depending on the contract.
No balance information is included.

Header Message-Response-Type: CREDIT_DEBIT_NOTIFICATION

Message structure

Debit Credit Notification message does not include the Message-Request-Id HTTP header!

Group Header – mandatory, preseneted once.
Notificaton – required for every account and currency. Repetitive per account number and currency. One notification block can include many entries.
Entry – optional and repetitive. Contains information about single entry.

Elements

Sample of debit notification

<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.054.001.02" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:camt.054.001.02 camt.054.001.02.xsd">
  <BkToCstmrDbtCdtNtfctn>
    <GrpHdr>
      <MsgId>MSGID_20220922111310_531549</MsgId>
      <CreDtTm>2022-09-22T11:13:10.825+03:00</CreDtTm>
    </GrpHdr>
    <Ntfctn>
      <Id>EE214204200000000000EUR20220922</Id>
      <ElctrncSeqNb>1</ElctrncSeqNb>
      <CreDtTm>2022-09-22T11:13:10.825+03:00</CreDtTm>
      <Acct>
        <Id>
          <IBAN>EE214204200000000000</IBAN>
        </Id>
        <Ccy>EUR</Ccy>
        <Ownr>
          <Nm>Testimiseks OÜ</Nm>
          <Id>
            <OrgId>
              <Othr>
                <Id>123412</Id>
              </Othr>
            </OrgId>
          </Id>
        </Ownr>
        <Svcr>
          <FinInstnId>
            <BIC>EKRDEE22</BIC>
            <Nm>COOP PANK AS</Nm>
            <PstlAdr>
              <AdrTp>BIZZ</AdrTp>
              <StrtNm>Maakri</StrtNm>
              <BldgNb>30</BldgNb>
              <PstCd>15014</PstCd>
              <TwnNm>Tallinn</TwnNm>
              <CtrySubDvsn>Harjumaa</CtrySubDvsn>
              <Ctry>EE</Ctry>
            </PstlAdr>
          </FinInstnId>
        </Svcr>
      </Acct>
      <TxsSummry>
        <TtlCdtNtries>
          <NbOfNtries>0</NbOfNtries>
          <Sum>0.00</Sum>
        </TtlCdtNtries>
        <TtlDbtNtries>
          <NbOfNtries>1</NbOfNtries>
          <Sum>25.00</Sum>
        </TtlDbtNtries>
      </TxsSummry>
      <Ntry>
        <NtryRef>1</NtryRef>
        <Amt Ccy="EUR">25.00</Amt>
        <CdtDbtInd>DBIT</CdtDbtInd>
        <Sts>BOOK</Sts>
        <BookgDt>
          <Dt>2022-09-22</Dt>
        </BookgDt>
        <ValDt>
          <Dt>2022-09-22</Dt>
        </ValDt>
        <AcctSvcrRef>71B2EA2</AcctSvcrRef>
        <BkTxCd>
          <Domn>
            <Cd>PMNT</Cd>
            <Fmly>
              <Cd>ICDT</Cd>
              <SubFmlyCd>BOOK</SubFmlyCd>
            </Fmly>
          </Domn>
        </BkTxCd>
        <NtryDtls>
          <TxDtls>
            <Refs>
              <AcctSvcrRef>71B2EA2</AcctSvcrRef>
              <InstrId>168</InstrId>
              <TxId>71B2EA2</TxId>
            </Refs>
            <AmtDtls>
              <TxAmt>
                <Amt Ccy="EUR">25.00</Amt>
              </TxAmt>
            </AmtDtls>
            <RltdPties>
              <Dbtr>
                <Id>
                  <OrgId>
                    <Othr>
                      <Id>123412</Id>
                      <SchmeNm>
                        <Prtry>COID</Prtry>
                      </SchmeNm>
                    </Othr>
                  </OrgId>
                </Id>
              </Dbtr>
              <Cdtr>
                <Nm>XXXXX OÜ</Nm>
                <Id>
                  <PrvtId>
                    <Othr>
                      <Id>16166605</Id>
                    </Othr>
                  </PrvtId>
                </Id>
              </Cdtr>
              <CdtrAcct>
                <Id>
                  <IBAN>EE584204200000000013</IBAN>
                </Id>
              </CdtrAcct>
            </RltdPties>
            <RltdAgts>
              <CdtrAgt>
                <FinInstnId>
                  <BIC>EKRDEE22</BIC>
                  <Nm>COOP PANK</Nm>
                </FinInstnId>
              </CdtrAgt>
            </RltdAgts>
            <RmtInf>
              <Ustrd>testimiseks</Ustrd>
            </RmtInf>
          </TxDtls>
        </NtryDtls>
      </Ntry>
    </Ntfctn>
  </BkToCstmrDbtCdtNtfctn>
</Document>

Sample of credit notification

<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.054.001.02" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:camt.054.001.02 camt.054.001.02.xsd">
  <BkToCstmrDbtCdtNtfctn>
    <GrpHdr>
      <MsgId>MSGID_20220922111311_419562</MsgId>
      <CreDtTm>2022-09-22T11:13:11.254+03:00</CreDtTm>
    </GrpHdr>
    <Ntfctn>
      <Id>EE214204200000000000EUR20220922</Id>
      <ElctrncSeqNb>1</ElctrncSeqNb>
      <CreDtTm>2022-09-22T11:13:11.254+03:00</CreDtTm>
      <Acct>
        <Id>
          <IBAN>EE214204200000000000</IBAN>
        </Id>
        <Ccy>EUR</Ccy>
        <Ownr>
          <Nm>XXXX OÜ</Nm>
          <Id>
            <OrgId>
              <Othr>
                <Id>16166605</Id>
              </Othr>
            </OrgId>
          </Id>
        </Ownr>
        <Svcr>
          <FinInstnId>
            <BIC>EKRDEE22</BIC>
            <Nm>COOP PANK AS</Nm>
            <PstlAdr>
              <AdrTp>BIZZ</AdrTp>
              <StrtNm>Maakri</StrtNm>
              <BldgNb>30</BldgNb>
              <PstCd>15014</PstCd>
              <TwnNm>Tallinn</TwnNm>
              <CtrySubDvsn>Harjumaa</CtrySubDvsn>
              <Ctry>EE</Ctry>
            </PstlAdr>
          </FinInstnId>
        </Svcr>
      </Acct>
      <TxsSummry>
        <TtlCdtNtries>
          <NbOfNtries>1</NbOfNtries>
          <Sum>25.00</Sum>
        </TtlCdtNtries>
        <TtlDbtNtries>
          <NbOfNtries>0</NbOfNtries>
          <Sum>0.00</Sum>
        </TtlDbtNtries>
      </TxsSummry>
      <Ntry>
        <NtryRef>1</NtryRef>
        <Amt Ccy="EUR">25.00</Amt>
        <CdtDbtInd>CRDT</CdtDbtInd>
        <Sts>BOOK</Sts>
        <BookgDt>
          <Dt>2022-09-22</Dt>
        </BookgDt>
        <ValDt>
          <Dt>2022-09-22</Dt>
        </ValDt>
        <AcctSvcrRef>71B2EA2</AcctSvcrRef>
        <BkTxCd>
          <Domn>
            <Cd>PMNT</Cd>
            <Fmly>
              <Cd>RCDT</Cd>
              <SubFmlyCd>BOOK</SubFmlyCd>
            </Fmly>
          </Domn>
        </BkTxCd>
        <NtryDtls>
          <TxDtls>
            <Refs>
              <AcctSvcrRef>71B2EA2</AcctSvcrRef>
              <InstrId>168</InstrId>
              <TxId>71B2EA2</TxId>
            </Refs>
            <AmtDtls>
              <TxAmt>
                <Amt Ccy="EUR">25.00</Amt>
              </TxAmt>
            </AmtDtls>
            <RltdPties>
              <Dbtr>
                <Nm>Testimiseks OÜ</Nm>
                <Id>
                  <OrgId>
                    <Othr>
                      <Id>123412</Id>
                      <SchmeNm>
                        <Prtry>COID</Prtry>
                      </SchmeNm>
                    </Othr>
                  </OrgId>
                </Id>
              </Dbtr>
              <DbtrAcct>
                <Id>
                  <IBAN>EE954204200000000026</IBAN>
                </Id>
              </DbtrAcct>
            </RltdPties>
            <RltdAgts>
              <DbtrAgt>
                <FinInstnId>
                  <BIC>EKRDEE22</BIC>
                  <Nm>COOP PANK</Nm>
                </FinInstnId>
              </DbtrAgt>
            </RltdAgts>
            <RmtInf>
              <Ustrd>testimiseks</Ustrd>
            </RmtInf>
          </TxDtls>
        </NtryDtls>
      </Ntry>
    </Ntfctn>
  </BkToCstmrDbtCdtNtfctn>
</Document>

Payment Initiation

Service for executing payments.

Payment initiation Request

POST [base-url]/gateway/api/payment

Coop Pank uses the request message format: Customer to bank Payment Initiation (XML new type pain.001.001.09 and old type pain.001.001.03) and it covers SEPA, SEPA Instant, Internal and SWIFT Payments.
One payment initiation message may contain multiple single payments.

For the status of imported payments Coop Pank returns Payment Status Report (XML type pain.002.001.12). One payment may have one to many statuses.

Payment confirmation methods

Every payment should be confirmed by the customer, most of them by using Strong Customer Authentication (SCA). This requirement comes from the Payment Service Directive 2 (PSD2).

Gateway API currently supports the following two options and the client himself can choose which one to use.

Pending Payments

Format for payment files: XML. Payment files will be processed and debited from the account after confirmation, not instantly. Payments must be confirmed in the Internet bank or in mobile application under Pending payments section and can be signed and confirmed only there. Internet Bank daily and monthly limits apply. At first the signer's personal limit (A limit) is taken in account. If it's not enough, the shared limit (A+A limit) will be used.

header Content-Type: application/xml

Signed Payments in DigiDoc Container

Estonian standard for payment files are BDOC or ASIC-E container. Internet bank daily and monthly limits and signature rights apply. If more than one signature is necessary to sign the payment, all signatures must be included in the container. Limit usage is taken into account for every signer - the requested amount is subtracted from every signer's limit.

header Content-Type: application/vnd.etsi.asic-e+zip

XML file should be named "request.xml". This file should be put into the BDOC or ASIC-E container and added required signature(s). Signed container has to be put into the body of the message. Internet Bank daily and monthly limits apply. At first the signer's personal limit (A limit) is taken in account. If it's not enough, the shared limit (A+A limit) will be used. The same process will apply for all the signatures added to the container.

Payment types and scheme selection

Gateway API currently supports following payment schemes:

• SEPA Instant (SCT Inst)
• Internal
• SEPA 
• SWIFT

Only automatic payment scheme selection decisions can be done.

• To other Coop Pank accounts - Bank internal payment
• If payment currency is EUR and the receiving bank is a member of the RT1 or TIPS clearing and settlement system for Instant payments - payment is sent as SEPA Instant. 
• If Instant payment cannot be processed for different reasons it is changed to SEPA.
• For other EUR payments in the European Economic Area (EEA) - SEPA payment.
• Other payments not in EUR or where beneficiary bank is not in the EEA - Swift payment.

Clearing times and limitations

More information could be found on Coop Pank's webpage under Payment section.

XML format (new pain.001.001.09 version)

Coop Pank is using custom version of pain.001.001.09.xsd

XML rules

Multiplicity (MULT.) informs how many times an element can or must be used, as defined by ISO standard.

1. 1..1 Shows that element is mandatory and can be presented only once.
2. 1..n Shows that element is mandatory and can be presented 1 to n times.
3. 0..1 Shows that element is optional and can be presented only once.
4. 0..n Shows that element is optional and can be presented 0 to n times. Note: True value of “n” represents unlimited number of occurrences.

Message structure

Group Header – mandatory, occurs once.
Payment Information – mandatory and repetitive. Contains information related to mostly the debit side of the payment.
Credit Transfer Transaction Information – mandatory and repetitive. Contains information related to the payment(s) included in the message.

Message root

Group header

Payment information

XML format(OLD pain.001.001.03 version)

XML format used by Coop Bank is a bit customized version of pain.001.001.03.xsd, still compliant with and has less restrictions than 1.4 version of the Estonian Banking Association implementation of pain.001.001.03. Coop Bank custom XSD is more restrictive that generic ISO 20022 XSD.
Every XML file valid according to Coop Bank custom XSD is also valid to generic pain.001.001.03.

Generic pain.001.001.03 message xml schema file is available at www.iso20022.org.

Request's Content-Type has to be 'multipart/form-data' and it has to contain XML file in "request" position, with its type also defined as "application/xml" or "application/vnd.etsi.asic-e+zip".

XML rules

Multiplicity (MULT.) Informs how many times an element can or must be used, as defined by ISO standard.

1. 1..1 One occurrence (required)
2. 1..n One or several occurrences (value for “n” represents total number of occurrences)
3. 1..3 Minimum one occurrence must be used and maximum 3 occurrences can be used. Note: True value of “n” represents unlimited number of occurrences.
4. 0..1 None or one occurrence to be used (optional)
5. 0..n None or several occurrences can be used (value for “n” represents total number of occurrences). Note: True value of “n” represents unlimited number of occurrences.

Message structure

Group Header – mandatory, occurs once.
Payment Information – mandatory and repetitive. Contains information related to mostly the debit side of the payment.
Credit Transfer Transaction Information – mandatory and repetitive. Contains information related to the payment(s) included in the message.

Elements

Payment information

Samples

Samples of payments and related messages for typical use cases depending on payment schemes and other details.

Response

XML format (ISO 20022 Customer Payment Status Report pain.002.001.12)

After payment request the customer will receive the response message - ISO 20022 Customer Payment Status Report (pain.002.001.12). This message is sent to the client to inform about the status of a payment instruction sent via Gateway API with Payment Initiation (pain.001.001.03) message.

Customer Payment Status Report refers to the original Payment Initiation message and gives feedback about the status of the process - provides positive, negative and pending status updates to original payments.
There can be many Customer Payment Status Reports per one Payment Initiation message - typically if any of the transactions was not accepted right away for any reason.

Payment status codes and descriptions

Statuses are reported on group level for the whole payment instruction (GrpSts and PmtInfSts tags) and separately for each payment (TxSts tag).
Group level statuses are reported only in the first payment response message after the initial request.
Further responses (if any) shall not contain GrpSts and PmtInfSts tags - you must process the result of every payment entry separately.

Group level statuses (OrgnlGrpInfAndSts.GrpSts and OrgnlPmtInfAndSts.PmtInfSts):

• RJCT – all payments in the forwarded XML file have been rejected.
• PDNG - pending, payments are waiting for confirmation in Internet Bank.
• PART – payment has been accepted, settlement is in process. Processing the payment is in the bank, it hasn't been debited from client account or sent to clearing system.
• ACSP - all payments in the forwarded XML file are in statuses of "In progress" or "Debited", but not debited from the customer's account yet. 

Single payment statuses (OrgnlPmtInfAndSts.TxInfAndSts.TxSts):

• PDNG - pending, payments are waiting for confirmation in Internet Bank.
• RJCT – rejected. One payment out of the group has been rejected (final status).
• ACSP – accepted, settlement in process. Payment is being processed by the bank, it has not been debited from client account nor sent to clearing system. At least one more status update must follow (either accept or reject).
• ACSC – accepted, settlement completed and payment has been debited from client account.  

Pending payments need confirmation in Internet Bank

When payment receives PDNG status after ACSP status (payment is accepted by the customer) it means that the payment needs confirmation in Internet Bank.

Payment rejection due to account balance or limits

By default, all payments will be rejected right away when there is not enough free balance or payments limits to execute the payment.

Message structure

Group Header – mandatory, occurs once. Set of characteristics shared by all individual payments included in the status report message.
Original Group Information And Status – occurs once. Refers to original Payment Initiation Group Level information.
Transaction Information And Status – optional and repetitive. Includes information about the original payment and its status.

Elements

Error codes

Error codes are subject to change. The xml returns the correct error description.

Appendix

Address structure (PostalAddress)

Code Set: Balance

Code Set: Bank transaction codes