aplonHUB, Credit Transfers Webhooks to backend and AML

1 New incoming payment
2 New incoming Financial Institution payment
3 New incoming CBPR+ pacs.008 payment
4 New incoming CBPR+ pacs.009 payment
5 New incoming Target2 pacs.008 payment
6 New incoming Target2 pacs.009 payment
7 Incoming request for payment
8 Incoming payment rejection
9 Incoming payment return
10 Incoming recall request
11 Incoming recall request rejection - SEPA
12 Incoming Cancellation Request response - MT
13 Incoming claim non receipt
14 Incoming Request to Modify Payment
15 Incoming Resolution Of Investigation
16 Incoming Status Request
17 Incoming Account Statement
18 AML API (for Incoming and Outgoing)

In order to notify core banking for every incoming payment or action, aplonHUB uses REST apis. It needs an endpoint for each of the following cases:

To notify core banking for new incoming SEPA or MT or P27 payments
To notify core banking for new incoming CBPR+ payments
To notify core banking for new incoming Target2 payments
To notify for other actions (e.g. payment rejections, payment returns, recall requests and recall request rejections). This is a single endpoint for all CT schemas
To call for AML check

See bellow the definitions for the APIs expected by the core banking.

NOTE:

for all the above requests and responses the content-type should be application/json
success is a request with status 200, and a non empty payload (in the payload you can return whatever you want like an ok or an id). It will be stored in aplonHUB for debugging reasons
sepaTrnHedSn is the aplonHUB's internal id. It's the id that uniquely identifies the payment in aplonHUB and you need it in order to make some actions with aplonHUB's exposed apis.

New incoming payment

Core banking should prepare an api to accept a payload like the following in order to be notified for any new incoming payment SEPA PACS.008 or an MT103

{
   settlementDate: '2020/04/01',
   currency: 'EUR',
   amount: 1.23,
   creditorName: 'Creditor name',
   creditorAddress: 'Creditor Address',
   creditorAccount: 'ACCOUNT',
   creditorAgent: 'TESTBICA',
   debtorName: 'Debtor Name',
   debtorAccount: 'DEBTORACCOOUNT',
   debtorAddress: 'Debtor Address',
   debtorAgent: 'TESTBICB',
   txId: 'TRANSACTIONID',
   endToEndId: 'ENDTOENDID',
   sepaTrnHedSn: 234,
   messageNameId: 'pacs.008',
   inOut: 'I',  //'I' for incoming or 'O' for outgoing
   chargesBearer:'SHAR', //'SHAR' or null for shared, 'BEN' for beneficiary, 'OUR' for ours.
   remittanceInformationUnstructured: [
     "remittance line 1",
     "remittance line 2",
     ...
   ]
}

NOTE: In case the response's http status is non 2xx then the request will be sent again in the next scheduler's run.

New incoming Financial Institution payment

Core banking should prepare an api to accept a payload like the following in order to be notified for any new incoming MT200 or MT202/MT202COV

{
   financialInstitutionOwnTransfer : {
      sepaTrnHedSn: 234,
      transactionReferenceNumber: 'string',
      valueDate: '2020/04/01',
      currency: 'EUR',
      interbankSettlementAmount: 1.23,
      sendersCorrespondent: {
         bic: 'string',
         id: 'string'
      },
      accountWithInstitution: {
         bic: 'string',
         id: 'string'
      },
      receivingBic: 'TESTBICA',
      senderToReceiverInformation: [
         "senderToReceiverInformationline 1",
         "senderToReceiverInformationline 2",
         ...
      ]
   },
   financialInstitutionTransfer : {
      sepaTrnHedSn: 234,
      transactionReferenceNumber: 'string',
      relatedReference: 'string',
      valueDate: '2020/04/01',
      currency: 'EUR',
      interbankSettlementAmount: 1.23,
      orderingInstitution: {
         bic: 'string',
         id: 'string'
      },
      intermediaryInstitution: {
         bic: 'string',
         id: 'string'
      },
      accountWithInstitution: {
         bic: 'string',
         id: 'string'
      },
      beneficiaryInstitution: {
         bic: 'string',
         id: 'string'
      },
      receivingBic: 'TESTBICA',
      isCov: false
   }
}

NOTE: In case the response's http status is non 2xx then the request will be sent again in the next scheduler's run.

New incoming CBPR+ pacs.008 payment

Core banking should prepare an api to accept a payload like the following in order to be notified for any new incoming CBPR+ pacs.008 payment

{
  "sepaTrnHedSn": 1,
  "inOut": "I",
  "messageNameId": "pacs.008.001.08",
  "customerCreditTransferCbprRequest": {
    "paymentIdentification" : {
      "instructionIdentification" : "BBBB/120928-CCT",
      "endToEndIdentification" : "ABC/4562/2012-09-08",
      "transactionIdentification" : "BBBB/120928-CCT/JPY/123/1",
      "uetr" : "00000000-0000-4000-8000-000000000000",
      "clearingSystemReference" : "String"
    },
    "paymentTypeInformation" : {
      "instructionPriority" : "NORM",
      "clearingChannel" : "String", //(valid values are "RTGS", "RTNS", "MPNS", "BOOK")
      "serviceLevel" : {
        "code" : "SDVA",
        "proprietary" : "String"
      },
      "localInstrument" : {
        "code" : "CRED",
        "proprietary" : "String"
      },
      "categoryPurpose" : {
        "code" : "String",
        "proprietary" : "String"
      }
    },
    "interbankSettlementAmount" : {
      "currencyCode" : "JPY",
      "value" : 100
    },
    "interbankSettlementDate" : "2012/09/29",
    "settlementPriority" : "String", //(valid values are "URGT", "HIGH", "NORM")
    "instructedAmount" : {
      "currencyCode" : "USD",
      "value" : 23.59
    },
    "exchangeRate" : 1.876,
    "chargeBearer" : "CRED",
    "chargesInformation" : [ {
      "amount" : {
        "currencyCode" : "USD",
        "value" : 12.34
      },
      "agent" : {
        "financialInstitutionIdentification" : {
          "bicfi" : "TESTBICA",
          "lei" : "String"
        }
      }
    }, {
      "amount" : {
        "currencyCode" : "USD",
        "value" : 12.34
      },
      "agent" : {
        "financialInstitutionIdentification" : {
          "bicfi" : "TESTBICA",
          "lei" : "String"
        }
      }
    } ],
    "instructingAgent" : {
      "financialInstitutionIdentification" : {
        "bicfi" : "BBBBUS33"
      }
    },
    "instructedAgent" : {
      "financialInstitutionIdentification" : {
        "bicfi" : "AAAAGB2L"
      }
    },
    "intermediaryAgent1" : {
      "financialInstitutionIdentification" : {
        "bicfi" : "INTERBIC"
      }
    },
    "intermediaryAgent1Account" : {
      "identification" : {
        "iban" : "String",
        "other" : {
          "identification" : "INTERAGTACCT",
          "schemeName" : {
            "code" : "String",
            "proprietary" : "String"
          }
        }
      }
    },
    "intermediaryAgent2" : {
      "financialInstitutionIdentification" : {
        "bicfi" : "String"
      }
    },
    "intermediaryAgent2Account" : {
      "identification" : {
        "iban" : "String",
        "other" : {
          "identification" : "INTERAGTACCT",
          "schemeName" : {
            "code" : "String",
            "proprietary" : "String"
          }
        }
      }
    },
    "intermediaryAgent3" : {
      "financialInstitutionIdentification" : {
        "bicfi" : "String"
      }
    },
    "intermediaryAgent3Account" : {
      "identification" : {
        "iban" : "String",
        "other" : {
          "identification" : "INTERAGTACCT",
          "schemeName" : {
            "code" : "String",
            "proprietary" : "String"
          }
        }
      }
    },
    "ultimateDebtor" : {
      "name" : "ABC1 Corporation",
      "postalAddress" : {
        "townName" : "String",
        "country" : "String",
        "streetName" : "String",
        "buildingNumber" : "String",
        "addressLine" : [ "Address line" ]
      }
    },
    "debtor" : {
      "name" : "ABC2 Corporation",
      "postalAddress" : {
        "townName" : "String",
        "country" : "String",
        "streetName" : "String",
        "buildingNumber" : "String",
        "addressLine" : [ "Address line" ]
      }
    },
    "debtorAccount" : {
      "identification" : {
        "iban" : "String",
        "other" : {
          "identification" : "00125574999",
          "schemeName" : {
            "code" : "String",
            "proprietary" : "String"
          }
        }
      }
    },
    "debtorAgent" : {
      "financialInstitutionIdentification" : {
        "bicfi" : "BBBBUS33"
      }
    },
    "creditorAgent" : {
      "financialInstitutionIdentification" : {
        "bicfi" : "AAAAGB2L"
      }
    },
    "creditor" : {
      "name" : "John",
      "postalAddress" : "String"
    },
    "creditorAccount" : {
      "identification" : {
        "iban" : "String",
        "other" : {
          "identification" : "23683707994215",
          "schemeName" : {
            "code" : "String",
            "proprietary" : "String"
          }
        }
      }
    },
    "ultimateCreditor" : {
      "name" : "AB3 Corporation",
      "postalAddress" : {
        "townName" : "String",
        "country" : "String",
        "streetName" : "String",
        "buildingNumber" : "String",
        "addressLine" : [ "Address line" ]
      }
    },
    "instructionForCreditorAgent" : {
      "code" : "String", //(valid values are "CHQB", "HOLD", "PHOB", "TELB")
      "instructionInformation" : "String"
    },
    "purpose" : {
      "code" : "K90",
      "proprietary" : "String"
    },
    "remittanceInformation" : {
      "unstructured" : [ ]
    }
  },
  "financialInstitutionCreditTransferCbprRequest": null
}

NOTE: In case the response's http status is non 2xx then the request will be sent again in the next scheduler's run.

New incoming CBPR+ pacs.009 payment

Core banking should prepare an api to accept a payload like the following in order to be notified for any new incoming CBPR+ pacs.009 payment

NOTE 1: In case the response's http status is non 2xx then the request will be sent again in the next scheduler's run.

NOTE 2: The same payload is used for CBPR+ pacs008 and pacs009. In each case the respective sub-element will be filled (customerCreditTransferCbprRequest for CBPR+ pacs.008 and financialInstitutionCreditTransferCbprRequest for CBPR+ pacs.009)

New incoming Target2 pacs.008 payment

Core banking should prepare an api to accept a payload like the following in order to be notified for any new incoming CBPR+ pacs.008 payment

NOTE: In case the response's http status is non 2xx then the request will be sent again in the next scheduler's run.

New incoming Target2 pacs.009 payment

Core banking should prepare an api to accept a payload like the following in order to be notified for any new incoming CBPR+ pacs.009 payment

NOTE 1: In case the response's http status is non 2xx then the request will be sent again in the next scheduler's run.

NOTE 2: The same payload is used for Target2 pacs008 and pacs009. In each case the respective sub-element will be filled (customerCreditTransferT2RtgsRequest for Target2 pacs.008 and financialInstitutionCreditTransferT2RtgsrRequest for Target2 pacs.009)

Incoming request for payment

Core banking should prepare an api to accept a payload like the following in order to be notified for any incoming Request for payment message (MTn91)

NOTE 1: In case the response's http status is non 2xx then the request will be sent again in the next scheduler's run.

Incoming payment rejection

For every outgoing pacs.008 we send we will receive a pacs.002 as an answer. The pacs.002 may reject/accept the whole message or some transactions of the message only. In any case, for every accepted/or rejected transaction we will send a request similar to the following to the core banking. If the rejectionReason is empty then consider the transaction as accepted from the ACH.

NOTE: In case the response's http status is non 2xx then the request will be sent again in the next scheduler's run.

Incoming payment return

For every outgoing payment we send with a pacs.008 or for every recall request we send with a camt.056, we may receive a payment return in a pacs.004. In that case we will send the following request to the core banking.

NOTE: In case the response's http status is non 2xx then the request will be sent again in the next scheduler's run.

Incoming recall request

For every incoming payment we receive with a pacs.008, we may receive an incoming recall request, for which, we may reply positively (pacs.004) or negatively (camt.029). In that case we will send the following request to the core banking in order to notify it for this incoming request.

NOTE: In case the response's http status is non 2xx then the request will be sent again in the next scheduler's run.

Incoming recall request rejection - SEPA

For every outgoing recall request we send, we may receive a negative response (camt.029). In that case we will send the following request to the core banking in order to inform it for this rejection.

NOTE: In case the response's http status is non 2xx then the request will be sent again in the next scheduler's run.

Incoming Cancellation Request response - MT

For every outgoing recall request we send, we may receive a response (MT196). In that case we will send the following request to the core banking in order to inform it for this rejection.

NOTE: In case the response's http status is non 2xx then the request will be sent again in the next scheduler's run.

Incoming claim non receipt

For every incoming pacs.008 we receive , we may receive a Claim Non Receipt (camt.027.001.06). In that case we will send the following request to the core banking in order to inform it about this message.

Incoming Request to Modify Payment

For every incoming pacs.008 we receive , we may receive a Request to Modify Payment (camt.087.001.05), and more specifically the value date of the payment. In that case we will send the following request to the core banking in order to inform it about this message.

Incoming Resolution Of Investigation

For every outgoing camt.027.001.06 or camt.087.001.05 we send we may receive an incoming Resolution Of Investigation Version8 (camt.029.001.08). In that case we will send the following request to the core banking in order to inform it about this message.

Incoming Status Request

In case we do not respond back in a time frame, for any incoming Claim Non Receipt, Request To Modify Payment or Recall Request , we may receive an incoming Status Request (pacs.028.001.01). In that case we will send the following request to the core banking in order to inform it about this message.

Incoming Account Statement

In some cases we may receive an MT940 or MT950 at the end of day. In that case aplonHUB will mark transactions (pacs.008/mt103) referred to the MT940/950 as settled and will create a new webhook for each transaction.

AML API (for Incoming and Outgoing)

For every incoming/outgoing payment, before further procesing, aplonHUB checks it for AML. An API is needed that will accept a request exactly like the New Incoming Payment request. As a response aplonHUB expects the following:

Http status 200 with keyword Pending in the response body
Http status 200 with keyword False Positive in the response body
Http status 200 with keyword Cleared in the response body.

In case you want to return your keywords you can specify them in the aplonHub's Configuration section accordingly. AplonHUB will resend the request in every scheduler's run while AML response remains Pending.