General Product Questions
What is Fabrick PSD2 Active Engine?
Fabrick PSD2 Active Engine is a set of unique APIs that allows access to a multiplicity of API interfaces of banks and other financial institutions provided by the PSD2 regulation. The solution can be used by AISPs (Account Information Service Providers) or banks that want to provide services based on access to their clients' accounts at other institutions (e.g.: multi-bank home banking, savings consulting services, risk analysis, etc.). The engine allows you to "connect one or more accounts" of end-customers and it will take care of updating them automatically on a daily basis in the background. The TPPs can easily manage these aggregated data (balances and account transactions) via API.
Which is the European country coverage?
Currently (October 2019), the engine covers almost completely the Italian market; by the end of 2019, it will be completely covered. During 2020, Fabrick will begin to connect the British, French and German ASPSPs in addition to the most important European banks of any country.
How many banks are connected? How do you access such banks (scraping, API, other interfaces)?
Currently (October 2019), 250+ banks are connected. We distinguish the connected banks in 3 levels based on the degree of confidence of the tests and the functionality of the same banks:
- High Quality Tested (Banks tested by our team with live accounts)
- Sandboxed Quality Tested (Banks that use the same core banking system and the same API interface as "High Quality Tested" banks)
- Standard Quality Tested (Banks tested in test environments)
Our API that reports supported banks returns all this information.
Fabrick USES ONLY PSD2 APIs. No screen scraping here... :-)
Do we need to take care of integrating each bank interface?
This is Fabrick's job!
The only aspect that can be a bit tricky in implementing an account aggregation service is the implementation of the final user SCA. Since the SCA process involves the end customer, the UX designer must correctly initialize the flow. However, these authentication processes are reduced to 3 or 4 scenarios that can be managed with the help of the PSD2 Active Engine tools.
Which SCA flows are supported? With which TAN methods?
All the known ones: redirect models (including OAUTH), embedded and decoupled. We also support all of the TAN methods that connected banks do provide.
Which consent types are supported?
All those of the Berlin Group NextGENPSD2 protocol: detailed, global, and bank-offered.
Which TPP certificates are supported (QWAC, QSEAL)?
Both QWAC and QSEAL.
The TPP must install its own qualified certificates (possibly both) in Fabrick's PSD2 Active Engine; the engine will then use the suitable one to correctly interact with each bank's interface. If needed, Fabrick is also able to help you with the purchase and acceptance of certificates.
Do you support AISP functionalities?
Yes, completely. You can create consents and access account and card information (both balances and transactions). Moreover, the engine provides access to multiple levels of aggregation: balances and transactions can be retrieved at account level, bank level (multiple accounts) or even at user level (multiple accounts on multiple banks).
Do you support PISP functionalities?
Yes, completely, starting from November 2019.
Do you support PIISP (card funds verification) functionalities?
Not for the time being. If you need such functionalities, contact us.
Which product documentation is available? In which languages?
We offer a full product documentation in English. You can find:
- Frequently Asked Questions (you are currently reading this)
- Detailed API technical documentation at endpoint level
Which data model / API standard is supported?
We have designed the engine on a high-level data model suited for a business use, so that you must not dive into the intricacies of each low-level bank interface details. Our APIs are designed to optimize the interaction from the perspective of a TPP, reasoning in terms of banks, users and accounts, without the need of delving into any specific standard technicalities. All of the conversion work between our high-level data model and each bank’s specific dialect is automatically managed under the hood. All of our APIs are RESTful, and the data exchange format is JSON.
Which kind of accounts can be aggregated?
All the accounts that each ASPSP makes available. In theory, all the accounts that are available in the PSU standard interface (i.e., home banking) should be made available by each bank, according to the RTS of the PSD2 Directive. Thus, the availability of cash, payment or current accounts, or personal/business accounts, totally depends on each ASPSP.
Do you provide account holder name information?
Yes, in all cases in which the connected banks supply them either.
Which kind of cards can be aggregated?
All the cards that each ASPSP makes available. In theory, all the cards that are available in the PSU standard interface (i.e., home banking) should be made available by each bank, according to the RTS of the PSD2 Directive. Thus, the availability of credit, debit, prepaid cards totally depends on each ASPSP.
Which levels of data aggregations are available?
The engine provides access to multiple levels of data aggregation. First, balances and transactions can be accessed at the single account (or card) level. Then, they are available at the bank level: multiple accounts (or cards) in the same bank are aggregated together. Finally, at the user level: multiple accounts (or cards) in multiple banks are aggregated together. This feature entails that, once the user has connected one or more accounts in one or more banks, you can retrieve all of his/her aggregate data with just one call.
How do you manage refreshment of aggregated data? Manually or automatically?
Both of them. The TPP can force the update at any time if the user is connected to its interface (using attended type access). The engine automatically updates each account/card at least 4 times a day as permitted by the RTS of the PSD2 Directive.
What happens to a user data after a consent expiration?
Nothing. User data remain available for use until an explicit deletion request, also if there is no active consent. All of the retrieved data can still be accessed without any limitation until the expiration date of the last active consent. If consent are renewed regularly, users do not experience any discontinuity. Even if consents are not renewed just after their expiration, our engine is able to automatically recover discontinuities whenever a new consent is available.
How do you manage consent renewal? Do you provide explicit callbacks before consent expiration?
Each consent contains the expiration date and time, so that you can provide renewal requests to your users with appropriate timings. We are also about to introduce an automatic callback mechanism to provide notification that consent expiration is approaching.
When PISP functionalities will be available?
We're going live by the end of November 2019!
Value Added Services Questions
Do you provide categorization services for transactions?
Yes, our PFM (Personal Finance Manager) engine is integrated with PSD2 Active Engine and provides a categorization of transactions based on the information available
Do you provide transaction enrichment services (e.g., localization)?
Yes, as part of the services of our PFM engine (Personal Finance Manager) for the transactions that allow it.
Do you support multiple tenant segmentation?
Yes, the data are segregated between one TPP and another.
General Technical Questions
Which execution environments are provided?
Sandbox (staging) and Live environments.
Is there a “Demo API” access available?
Yes, we can provide a sandbox access to let you try the engine. All of the functionalities are supported, given that ASPSPs are accessed exclusively on their sandbox environments.
Is Fabrick PSD2 Active Engine available also on premise?
No, PSD2 Active Engine is available only as-a-service. Wouldn't an API platform available on premise be a strange proposal? :-)
How do you manage data persistence?
Data persistence is managed on our high-availability data center. We pay great attention to segregation between each TPP data to prevent data breaches. By no mean it is possible to access user data belonging to any other TPP.
How do you comply to GDPR? Can we export user data? Can we delete user data?
We support privacy by design. All data can be managed on a user basis, exported and also deleted.
How do you manage logging/tracing data if user data is deleted?
The TPP has total control of its data via API. Including the freedom to delete them.
How long do you keep logging/tracing data on your systems?
It depends. Tipically, 10 years.
Which service levels do you guarantee? Do you set up any SLA with customers?
We have a standard SLA based on 4 drivers:
- Availability of the service;
- Taking charge of the issues;
- Resolution of issues;
- Availability of development environments.