Skip to main content

FSP Standalone

In the standalone mode it is the aggregator’s ownership to communicate the Money-In attributes and specify the allocation of related shares among the various clients. In this page we will decribe how to manage the process throuch API.

Creating money-in request

The POST CreateMoney-in service enables the aggregator to communicate an expected credit to FSP, that is, the data needed to verify the aggregator’s account movements. Below is an example of how to use this service:

Input example:

The details of the fields included in the request are explained in the technical documentation of the service.

Here, some notes on how to use the service:

  • The currencies used must be among those supported by FSP.
  • All amounts in the CreateMoney-in request must use the same currency.
  • FSP does not support currency conversion.
  • The reconciliationCallbackUri attribute, if provided by the caller, allows FSP to send a callback to the client system to notify the outcome of the accounting reconciliation.
  • The service may result in either OK or KO.
  • OK means that the reconciliation process has been taken in charge; if it is successful, FSP initiates Cashin and Cashout as specified in the contract with the clients.
  • Clients are identified by their VAT number.
  • Only identifiers of clients active in the aggregator’s domain are allowed.
  • clientIds must not be repeated within the request.
  • The createMoney-in request is identified by the creditTransferId field.
  • The creditTransferId value can be reused only after the previous request has completed reconciliation with a KO outcome.

FSP reconciliation process

Once the expected credit data has been acquired, FSP reviews the observed credits received in the aggregator’s account. Reconciliation is performed between an expected credit and an observed credit that share the same unique identifier, transferId. The reconciliation then verifies that the two credits match according to the following rules:

  • The acquirer associated with the expected credit must be correctly identified and recognized.
  • Both credits must be denominated in the same currency.
  • Expected and observed credit amounts must be identical.

The reconciliation process may result in three outcomes:

  • OK: Reconciliation has been successfully completed.
  • KO: At least one reconciliation rule has been violated; in this case, the request can be resubmitted with corrected data.
  • IN_PROGRESS: Reconciliation is still ongoing, as not all required data regarding the credits is yet available.

When reconciliation is eventually completed, the outcome is automatically updated to either OK or KO.

Reconciliation callback

FSP may send a callback to the caller to notify the outcome of the reconciliation process. This occurs if the reconciliationCallbackUri field is provided in the POST CreateMoney-in request. The structure of the callback payload is illustrated below.

{
"reconciliationOutcome": {
"creditTransferId": "TRN/CRO",
"reconciliationStatus": "OK||KO||IN_PROGRESS",
"moneyIn": {
"amount": {
"value": 100,
"currency": "EUR"
}
},
"observedTransfer": {
"amount": {
"value": 100,
"currency": "EUR"
}
}
}
}

The following table describes the structure of the callback payload.

FieldTypeMandatoryUsage
reconciliationOutcomeObjectYContainer of data response.
reconciliationOutcome.creditTransferIdStringYBank transfer identifier, TRN/CRO, shared by the expected and observed credits.
reconciliationOutcome.reconciliationStatusEnum: OK, KO, IN_PROGRESSYReconciliation status.
reconciliationOutcome.moneyInObjectYAmount details.
reconciliationOutcome.moneyIn.amountObjectYCredit amount.
reconciliationOutcome.moneyIn.amount.valueNumber, two decimalsYAccount lifecycle tracking.
reconciliationOutcome.moneyIn.amount.currencyString ISO 4212YCurrency code, 3 chars.
reconciliationOutcome.observedTransferObjectYDescription of the observed credit.
reconciliationOutcome.observedTransfer.amountObjectNAmount details if available.
reconciliationOutcome.observedTransfer.amount.valueNumber, two decimalsNAmount details if available.
reconciliationOutcome.observedTransfer.amount.currencyString ISO 4212NCurrency code if available.

The status IN_PROGRESS is reported by the callback when reconciliation has not been completed within the defined time threshold.

The callback is sent using the POST method to the endpoint specified in the POST CreateMoneyIn request. If the invocation fails, FSP applies its retry policies. The callback is invoked without an authorization mechanism, however, Fabrick can provide the list of IP addresses to be whitelisted.