Skip to main content

FPP support for the PSU

View as Markdown

PSU Onboarding​

To allow FPP to access its customers' account data, each customer has to complete the onboarding phase on Fabrick. This phase involves a verification of the identity of the PSU plus a service acceptance part (see details in the specific technical document).

Check the status of the PSU​

Once the PSU has been invited to proceed with the onboarding phase, it will obviously be necessary, on the FPP side, to control its flow, both to verify its conclusion (and therefore proceed with the service offered) and to support it in the event of any blocks during the process.

For this reason the following lines indicate the guidelines that the FPP will have to implement (the API details are indicated in the specific section).

POST SearchUsers​

The POST SearchUsers API will return the userCompanyCode created only after acceptance of the contract during the onboarding phase.

Therefore, se the customer is not present it means that he has not yet completed the onboarding phase. We remind you that the link lasts 3.5 hours. In case the customer has not finished, simply create a new link via the POST CreateOnBoardingUser API by entering exactly the same data as the PSU. Fabrick will recognize the customer and will redirect him to the login page. Once the customer enters their credentials indicated during registration, he will be redirected to the step he arrived the previous time and will thus be able to complete onboarding correctly.

GET getUserDetails​

If, however, the POST SearchUsers API returns the desired customer then it will be necessary to invoke the GET getUserDetails and check the status of the customer itself.

By evaluating the output as indicated in the specific document you will know the customer's situation to behave accordingly:

  • DATA_CHECK: the customer has a risk score such that further checks are necessary by Fabrick. In this case this information can be communicated to the customer. Checks can last a maximum of 7 days. Please contact Fabrick se this time limit is not respected.

  • USER_ACTION: in this case the customer will have to correct something, for example he may have inserted a non-readable document. In this case, the PSU will receive the instructions via email (see Onboarding result and email communications section in the PSU Guide doc). It will therefore be sufficient for the FPP to invite the PSU to check the personal email. If the link in the customer's email has expired then you will have to invoke POST CreateOnBoardingUser and send the new link to the customer

  • REJECTED: in this case it was not possible to onboard the customer because the AML or CSSE checks gave a negative result. In this case, although rare, for privacy reasons it is not possible to share all the information, but the FPP may ask Fabrick for clarification.

    In this case Fabrick unfortunately will not be able to give further information to the FPP. To know more details regarding the reasons for such REJECTED the PSU may write directly to: Fabrick Support Onboarding onboardingSupport@fabrick.com.

    Summing up:

  • for any reason in which the customer is not present, FPP will have to create a new link via the POST CreateOnBoardingUser.

  • If the customer is unable to access and log in to the dashboard, the FPP will have to invoke the GET getUserDetails to understand the reason as indicated above.

After the aforementioned checks, se the PSU still encounters problems accessing, FPP will have to contact Fabrick.

GET getAccounts​

However, se the customer status is correct and complete, but the FPP is still unable to display the list of accounts, then it will be sufficient to check the hasActiveAuthorizations parameter of the GET getUserDetails API: se this parameter is false the customer must be invited to authorize at least one account via access to the portal (full version or simplified version via the link created with the POST UpdateAggregation API).

In case of user with active authorization (hasActiveAuthorizations true) the FPP should add a check on the expiration of the consent. The information can be retrieved through two different services:

  • POST SearchConsents: returns the list of expiring consents (consents with past expiration date are not shown) for each customer. No account details are returned, so it is useful se FPP wants to send a reminder to the customer indicating that he has at least one expiring consent. - GET getAccounts: returns the expiration date of that particular account in order to indicate to the customer also the precise account.

In case of not valid consent the customer has to be redirected to the Fabrick page via the POST UpdateAggregation service.