Version 4.0.6

Changes related to version 4.0.6

Fields constrains

Please take care that it could be a breaking change. For example, if you have pre-recorded data that doesn't match the checks, they could now be rejected.

To prevent values to be rejected by the bank, we have added a new fields for constraints definition in options on debtor name, creditor name and remittance information fields for each payment product. E.g.:

options.{payment_product}.PaymentInitiationRequestOptions.Debtor.NameConstrains.MinLength = 1;
options.{payment_product}.PaymentInitiationRequestOptions.Debtor.NameConstrains.MaxLength = 40;
options.{payment_product}.PaymentInitiationRequestOptions.Debtor.NameConstrains.Regex = "^[a-zA-Z0-9-/:().,? '+]{1,40}$";
options.{payment product}.PaymentInitiationRequestOptions.Debtor.NameConstrains.AcceptedChars = "a-zA-Z0-9-/:().,? '+";

options.{payment_product}.PaymentInitiationRequestOptions.Recipient.NameConstrains.MinLength = 1;
options.{payment_product}.PaymentInitiationRequestOptions.Recipient.NameConstrains.MaxLength = 40;
options.{payment_product}.PaymentInitiationRequestOptions.Recipient.NameConstrains.Regex = "^([a-zA-Z0-9?:'\\/\\()+, \\-\\.áâäàåãÄÅÁÂÀÃÇçêëèéÊËÈÉïîìíÍÎÏÌôöòõóÓÖÔÒÕûùúüÚÛÙÜñÑýÝÿ]{1,40})$";
options.{payment_product}.PaymentInitiationRequestOptions.Recipient.NameConstrains.AcceptedChars = "a-zA-Z0-9?:'\\/\\()+, \\-\\.áâäàåãÄÅÁÂÀÃÇçêëèéÊËÈÉïîìíÍÎÏÌôöòõóÓÖÔÒÕûùúüÚÛÙÜñÑýÝÿ";

options.{payment_product}.PaymentInitiationRequestOptions.RemittanceInformationUnstructuredConstrains.MinLength = 1;
options.{payment_product}.PaymentInitiationRequestOptions.RemittanceInformationUnstructuredConstrains.MaxLength = 140;
options.{payment_product}.PaymentInitiationRequestOptions.RemittanceInformationUnstructuredConstrains.Regex = "^([a-zA-Z0-9?:'\\/\\()+, \\-\\.áâäàåãÄÅÁÂÀÃÇçêëèéÊËÈÉïîìíÍÎÏÌôöòõóÓÖÔÒÕûùúüÚÛÙÜñÑýÝÿ]{1,140})$";
options.{payment_product}.PaymentInitiationRequestOptions.RemittanceInformationUnstructuredConstrains.AcceptedChars = "a-zA-Z0-9?:'\\/\\()+, \\-\\.áâäàåãÄÅÁÂÀÃÇçêëèéÊËÈÉïîìíÍÎÏÌôöòõóÓÖÔÒÕûùúüÚÛÙÜñÑýÝÿ";

MinLength, MaxLength and AcceptedChars could be used to display the constraints to the end-user. Keep in mind that the space character, if present, may not be so much visible in the displayed string.

We don't have constrains for all the connectors and, for the one we have, we don't have necessarily all the constrains. So be prepared to null valued fields.

Early model check

Valid in both gateway or TPP/Direct modes.

To send back to you clearer error messages, we are now checking the model you send us in AIS initiation or PIS initiation before sending the data to the bank.

🚧

You should be doing those test on your side before calling our API!

You will receive an 422 unprocessable entity HTTP status with an error message and the target field. Examples:

AIS single field empty:

{
  "Property":"accountsAccessRequest.singleAccount.IBAN",
  "Message":"The IBAN can not be empty or null."
}

PIS missing required field:

{  
  "Property": "Recipient.Address.BuildingNumber",  
  "Message": "The property BuildingNumber is required, can not be null or empty"  
}

IBAN not valid:

{
  "Property": "Debtor.IBAN",
  "Message": "The IBAN:(LU2806100000226001EUR) is incorrect."
}

PIS name not matching regex:

{
  "Property": "Debtor.Name",
  "Message": "Property Debtor.Name: 'Doe%' does not match with the Regex: ^[a-zA-Z0-9-/:().,? '+]{1,10}$."
}
  • Check against connector's AIS options
    • Access option: presence of IBAN(s) in expected field singleAccount, transactionAccounts and balanceAccounts
    • Required currency presence and among official three letters ISO 4217 list
  • Check against connector's PIS options
    • required fields,
    • field constrains: length, allowed characters for
      • debtor name
      • recipient name
      • remittance information
    • currency among official three letters ISO 4217 list
    • additional properties required & regex template
    • Requested execution date
      • today or in the future
      • against options' specificPaymentDate
    • Regulatory reporting codes against options' regulatoryReportingCodes
    • End to end id required and length <= 35 chars
    • email required and light syntax validation "^[a-zA-Z0-9.!#$%&'+/=?^`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)_$"
  • IBAN for AIS's accounts and PIS's debtor and recipient
    • required
    • checksum
    • country among two letters ISO 3166-1 list
    • note that we cannot check if the IBAN really exists and, for the debtor, belongs to the bank of the connector

Added settings Id in User Context (TPP/Direct mode)

We have added a new (optional) string field "settingsId" in BankSettings of calls to allow you to memorize which bank settings you have used to establish a consent. This could be used when you have multiple certificates or bank credentials, e.g. switching to a new certificate. Example:

{
  "connectorId": 1,
  "bankSettings": {
    "settingsId": "11a3c36a-f8ef-4e10-b642-d8a9b87c6797",
    "ncaId": "PSDBE-...",
    "appClientId": "AZ98N47h6g...",

When you call get accounts, you'll found back the settingsId in the answer, for each accounts, in balance and transaction:

{
  "accounts": [
    {
      "id": "string",
      "currency": "string",
      "iban": "string",
      "description": "string",
      "transactionsConsent": {
        "consentId": "string",
        "validUntil": "2022-11-24T11:17:33.547Z",
        "status": 0,
        "statusAt": "2022-11-24T11:17:33.547Z",
        "settingsId": "11a3c36a-f8ef-4e10-b642-d8a9b87c6797"        
      },
      "balancesConsent": {
        "consentId": "string",
        "validUntil": "2022-11-24T11:17:33.547Z",
        "status": 0,
        "statusAt": "2022-11-24T11:17:33.547Z",
        "settingsId": "11a3c36a-f8ef-4e10-b642-d8a9b87c6797"        
      }
    }

This allows you to see which settings has been used during account access request to use them when getting balances or transactions or during the payment initiation to use htem

🚧

Only settingsId is stored in the usercontext. No certificates, no credentials are stored. You must pass the credentials and certificates in later calls as before

Added bank grouping in list of banks

As some banks have local branches, we have added a new field bankGroup to the list of banks call /ob/banks. Example with French bank Crédit Agricole (not exhaustive)

{
    "fullname": "Crédit Agricole de Normandie",
    "connectorID": 1171,
    "logoURL": null,
    "countryISO": "FR",
    "verStable": null,
    "status": 0,
    "bankGroup": "Crédit Agricole"
  },
  {
    "fullname": "Crédit Agricole de Normandie Seine",
    "connectorID": 1172,
    "logoURL": null,
    "countryISO": "FR",
    "verStable": null,
    "status": 0,
    "bankGroup": "Crédit Agricole"
  },
  ...

Bank grouping will not occur when the banks have different names like BE BNP / BE FINTRO / BE Hello Bank or when there is too few banks and with different "lines" like BancoPosta and BancoPosta Business.

Usage of status field in list of banks

When we detect an error in calls to a bank that is not related to user input, an analysis is done to determine the nature and reproductibility of it. If we estimate that there is a permanent problem of communication with the bank, we change the status of the bank/connector:

  • 0: production ready
  • 1: pre-production ready, to be tested
  • 2: connector issue
  • 3: ASPSP issue. Can be used but issues might occur
  • 4 and above: connector unusable in production

You may then filter them depending on this status.

Connector improvement or correction

  • BE: ING extraction of counterpart IBAN and name from remittance information for intraday transactions
  • FR: Banque Postale
  • ES: ANDBANK, Banca March, Banco Mediolanum, Banco Pichincha, Banco Sabadell, Banco Santander, Bankia, Bankinter, Bankoa, BBVA, Caixabank, Caja Arquitectos, Caja Rural, Cajamar, Cajasur, Colonya, Eurocaja Rural, EVO Banco, Fiare Bancaetica, Ibercaja, Inversis, Kutxabank, Laboral Kutxa, Openbank, Renta4, Self Bank, Unicaja Banco, Wi Zink
    • Enhanced payment details
    • Creditor address required for international payment
  • Fix requesting all the accounts by providing an empty IBAN list
    • BE: banque de Luxembourg, banque Transatlantique
    • LU: Spuerkeess, banque de Luxembourg, banque de Patrimoines Privés, banuqe Transatlantique
  • Fix requesting all the accounts
    • BE: KeyTrade Bank, Van Breda, AXA Bank, EuropaBank, BPost Bank, Nagelmackers, Crelan, VDK Bank, CPH, Neuflize OBC, AION
    • DE: CommerzBank, comdirect
    • FR: Lazard Frères Banque, Crédit Municipal, Orange Bank
    • NL: Credit Europe
  • Consent is linked. There can be only one consent by PSU so when requesting access to an account, all the currently connected accounts has to be included
    • BE: KeyTrade Bank, Van Breda, AXA Bank, EuropaBank, BPost Bank, Nagelmackers, Crelan, VDK Bank, CPH, Neuflize OBC, AION
    • DE: CommerzBank, comdirect
    • FR: Lazard Frères Banque, Crédit Municipal, Orange Bank
    • NL: Credit Europe
  • Getting payment status failing when payment refused
    • PT: Caixa Economica Montepio Geral, Banco de Investimento Global Espanha, Unicre - Instituição Financeira de Crédito, Caixa de Credito Agricola Mutuo de Torres Vedras, Caixa de Credito Agricola Mutuo de Bombarral, Caixa de Credito Agricola Mutuo da, Chamusca, Caixa de Credito Agricola Mutuo de Mafra, Cofidis, Novo Banco dos Acores, Novo Banco, Caixa Geral de Depositos, Banco BIC Portugues, Caixa de Credito Agricola Mutuo de Leiria, Banco Portugues de Gestao, Banco de Investimento Global, Banco CTT, Banco Atlantico Europa, Caixa Economica da Misericordia de Angra do Heroismo, Crédito Agricola, Bankinter, Banco Comercial, Portugues, Banco Santander Totta, Banco Activobank, Banco BPI
    • FR: Caixa Geral de Depositos France
    • FR: Banque Populaire/*, Banque de Savoie, Banque BCP, BTP Banque, Banque Palatine, Caisse d'Epargne/*, Crédit Coopératif, Natixis Global Trade, Natixis Wealth Management
      • Fix in payment

Added connectors

  • Revolut in GB, LT, BG, PL, HR, EE, CY, LV, GR, RO, MT, SI, SK, HU, CZ, AT, PT, IT, FR, DK, BE, FI, DE, IS, LU, LI, SE, ES, NL