PSD2Hub list of functionalities | Banqware Help Center

ID	API version	Area	Functionality	API methods	Standard/ Premium	Details
Business Parameterization area: PSD2Hub provides and manages the parameterization of the following logical elements: country - each of the banks is assigned to one of the available countries bank (ASPSP) - PSD2Hub allows versioning of the API exposed by the bank, as well as connecting different connectors (scraping, PSD2, etc.) api-clientID - specifies the PSD2Hub API client and the context of the calls. This parameter, passed in the header, allows you to handle API calls PSD2Hub by one TPP in the context of different channels, versions, etc. connector - interface allowing access to the bank's API. Each connector can appear in several logical instances and support different banks under one API standard. There is a dedicated parameterization of the connector for each bank
PB1	1.0	Business Parameterization	List of countries defined in PSD2Hub.	GET /api/country	S	Each country is parameterized by: names, codes, logo (flag), ISO code
PB2	1.0	Business Parameterization	List of banks managed by PSD2Hub supported for the indicated country	GET /api/country/{isoCode}/bank	S	Country indicated by ISO code
PB3	1.0	Business Parameterization	Banking versioning and linking with the appropriate value api-clientID= version (table: ApiClientBank, keys: ApiClientID, BankID, BankVersionID)	GET /api/country/{isoCode}/bank The query returns a different list depending on the api-clientID parameter in the header	S	Ability to support many different versions of the ASPSP API depending on the channel and the front-end version.
PB4	1.0	Business Parameterization	Smooth migration of accounts between bank versions (scraping->API)		S	Scraping specific. Intended for migration robot->PSD2
PB5	1.0	Business Parameterization	Download bank details	GET /api/bank/{bankID}	S	Each bank parameterized by: names, codes, logo (color characterizing the bank), AIS and PIS parameters specific for a given Bank
PB6	1.1	Business Parameterization	Identification of banks by different types of identifiers (complex identifiers)		S/P
PB7	1.1	Business Parameterization	Dynamically generated structure of login pages to banks	GET /api/bank/{bankId}/authorize	S	Robot Specific. JSON generated on the PSD2Hub side and returned by the API. JSON should be dynamically rendered by the front-end. For robots, rules for form validation (regExp) and field formats are supported. Optional configuration of additional parameters needed for SCA for PSD2. For selected login / SCA changes on the connector side, a change in the code will be required.
PB8	1.1	Business Parameterization	Dynamically generated structure of login pages - language efficiency	GET /api/bank/{bankID}/authorize	S
K1	1.0	Business Parameterization	Contexts (api-clientID)	All methods - the api-clientID parameter must be passed in the header	S	Allow for front-end versioning and use of one instance of PSD2Hub through different channels
K2	1.0	Business Parameterization	The list of banks is variable depending on the context (api-clientID)		S
K3	1.0	Business Parameterization	Configuration of PSD2 connectors varies depending on the context (api-clientID)		S
K4	2.0	Business Parameterization	Versioning of connectors PSD2		S/P	Planned Q3 2019 - versioning of connectors for API lifecycle management APSSPS
AIS area: a set of PSD2Hub API methods allowing aggregation of data from the bank (ASPSP) various SCA variants are supported. aggregation sessions are handled asynchronously (TPP polls for session status or (option) receives status via callback). the key assumption of PSD2Hub is identical (from the point of view of TPP) how to start a session for each bank, regardless of how the data is collected (scraping, PSD2 etc.) and the type of API data on bills and transactions collected from ASPSP are saved in intermediate structures (stage) in the unchanged form (raw) and within the same session, transformed into a unified logical model. Data downloaded from ASPSP are permanently saved in LDS (Local Data Store) asking for data from LDS returns the last known state, without updating data from ASPSP. The query can simultaneously run a data update session in the background.
A1	1.0	AIS	Initiation of the AIS session by providing bankID	POST /api/bank/{bankID}/authorize	S
A2	1.0	AIS	Download session status (polling)	GET /api/bank/session/{sessionID}	S
A3	2.0	AIS	Download session status (callback URL)	GET /api/bank/session/{sessionID}	S/P	Separation of bill collection, account details and transactions for intermediate status stages (approval statuses)
A4	1.0	AIS	Account migration between different versions of the APSPS API		S	Including migration from scraping to PSD2.
A5	1.0	AIS	Support for two-step authentication	POST /api/bank/{bankId}/authorize	S	Robot Specific
A6	1.0	AIS	Activation of accounts selected by the user in the session AIS	POST /api/bank/session	S	Selection which customer accounts will be activated
A7	1.0	AIS	Aggregation and saving the list of accounts in LDS		S
A8	1.0	AIS	Aggregation and recording of account details in LDS		S
A9	1.0	AIS	Aggregation and record of the list with transaction details in LDS		S
A10	1.0	AIS	Downloading the list of bills for the indicated user	GET /api/bankaccount	S
A11	1.1	AIS	Downloading the transaction list for the indicated user and account	GET /api/ /transaction	S	Support for pagination On the PSD2Hub side all transactions in different statuses (vide PolishAPI) are stored and returned in one structure (including blockade) For PolishAPI it is an opportunity to query for transactions in a given status - GET, status provided in the URL (extension of the current GET / api / transactions)
A12	1.0	AIS	Get details of the specified transaction	GET /api/transaction/{transactionId}	S
A13	1.0	AIS	Mapping transactions from AFI to LDS		S	Unification of data issued by PSD2Hub regardless of the origin of the data (source agnostic)
A14	1.0	AIS	Mapping of account parameters from the AFI format to LDS		S	Unification of data issued by PSD2Hub regardless of the origin of the data (source agnostic)
A15	1.0	AIS	Update of invoices, account details and background transactions (for active accounts) for accounts of the indicated user	GET /api/bankaccount&RefreshActiveAccounts=true	S	The possibility of automatic updating for an authorized user
A16	1.0	AIS	Cyclic refreshing of active batch accounts for which the IsSyncOffline = 1 flag has been set		S	Possibility of setting the periodicity or indication of batch hours
A17	2.0	AIS	Account restrictions		P	Analysis of flags related to the restriction on the account (PolishAPI) - (what account is what, for example, credit, charge)
User management area (PSU): By the design, PSD2Hub does not receive or manage PSU data (**). TPP transmits the unique PSU identifier (transmitted on the TPP side) with each call.
ZU1	1.0	User management (PSU)	Work creating the PSD2Hub user for the newly passed identifier at the AIS initiation	POST /api/bank/{bankId}/authorize	S	At the start of authorization, the user is created automatically
ZU2	1.0	User management (PSU)	Creating and deleting a user through the API	POST /api/user DELETE /api/user/ {userId}	S	Possibility to create and delete a user on demand
Data management area in LDS: data retention mechanisms and support for GDPR
ZD1	1.0	Data management in LDS	Data retention		S/P
ZD2	1.0	Data management in LDS	GDPR		S/P
Area Support for business clients: PSU service in the context of a business client
KB1	2.0	Support for business clients	Assigning an account to the company (company) + assigning users to the company		S/P
Area Account management: a set of PSD2Hub API methods for managing the list of user accounts Account business data is synchronized with ASPSPs In LDS, a collection of additional (local) account parameters is managed (own name in LDS, synchronization flags, etc.)
ZR1	1.0	Account management	Download details of the invoice	GET /api/bankaccount/{accountId}	S
ZR2	1.0	Account management	Change of local parameters (LDS) of the account (managed by PSD2Hub)	POST /api/bankaccount/{accountId}	S
ZR3	1.0	Account management	Add / download / remove logo (graphic file) to the invoice	GET	POST	DELETE /api/image/{bankAccountId}
Monitoring area: a set of mechanisms to ensure and monitor the availability of services exposed by PSD2Hub
M1	1.0	Monitoring	The method checking the API availability status - used by load-balancer	HEAD /api/status/check	S
M2	1.1	Monitoring	The method that checks the API version	GET /api/status/version	S
M3	1.0	Monitoring	API access monitoring scripts (power shell)		S
M4	1.1	Monitoring	Escalation of errors through an external endpoint		S
Credentials area: a mechanism that allows storing and managing user data for logging in to the bank (only for scraping)
C1	Robot specific	Credentials (only robots)			S	Robot specific
C2	Robot specific	Credentials (only robots)		DELETE /api/credential	S	Robot specific
C3	Robot specific	Credentials (only robots)			S	Robot specific
PSU authorization area: supported mechanisms of strong client authentication (SCA) and management of keys issued by ASPSP
AU1	1.0	PSU authorization	Support for oAuth 2.0 with the generation of consent uri by PSD2Hub		S
AU2	1.0	PSU authorization	Support for oAuth 2.0 with downloading consent URL from ASPSP		S
AU3	1.0	PSU authorization	Saving and storing keys and consent on the PSD2Hub side		S/P
AU4	1.0	PSU authorization	OAuth 2.0 support with front-end authorization token (redirect-uri indicates front-end)	POST /api/bank/{bankId}/authorize	S
AU5	2.0	PSU authorization	OAuth 2.0 support with the token download via endpoint (redirect-uri) issued by PSD2Hub		S/P
AU6	1.0	PSU authorization	Exchange of the authorization token for an access token and refresh token		S
Security area: supported security mechanisms in TPP-ASPSP communication
B1	1.0	Security	Support for JWT (JWS)		S
B2	1.1	Security	Support for OpenID		S
B3	1.0	Security	Support for the API gateway certificate		S	Divided into individual ASPSP
B4	1.0	Security	Support for outgoing traffic via the GtW API		S	Management of endpoints issued by ASPSP and covering them with endpoints on the gate
Agreement management area: a set of PSD2Hub API methods to manage the user's consent
ZZ1	1.1	Agreement management	Downloading the consent list for a given user	GET /api/consent	S
ZZ2	1.1	Agreement management	Removal of the indicated consent for a given user	DELETE /api/consent	S
PIS area: a set of PSD2Hub API methods that allow initiating payments in ASPSP various SCA variants are supported. aggregation sessions are handled asynchronously (TPP polls for payment status or (option) receives status via callback). the key assumption of PSD2Hub is identical (from the point of view of TPP) the method of initiating payments for each bank, regardless of the type of API initiated payments are permanently saved in the LDS (Local Data Store) as a payment object
P1	R2	PIS	Initiating payments	POST /api/bank/{bankId}/bankaccount/{iban}/payment	S/P
P2	R2	PIS	SCA support in PIS		S
P3	R2	PIS	Downloading the payment status	GET /api/bank/{bankId}/bankaccount/{iban}/payment/{paymentId}	S
P4	R2	PIS	Downloading the payment status (callback)		S/P
P5	R2	PIS	Downloading the payment list for the indicated user	GET /api/payment	S
P6	R2	PIS	Downloading details and payment status for an indicated user. It triggers the query of PISPs	GET /api/bankaccount/{iban}/payment/{paymentID}	S
Area Analysis of transactional data: a set of PSD2Hub API methods to support enriched data and transactional data analysis mechanisms
ADT1	R2	Analysis of transactional data	Downloading a list of metrics (KPIs) for an indicated user	GET/api/kpi/getKpiList	S/P
ADT2	R2	Analysis of transactional data	Get the value of a metric (KPI) for the indicated user	GET/api/kpi/getKpiValues	S/P
ADT3	R2	Analysis of transactional data	Get details of the indicated metric (KPI)	GET/api/kpi/getKpiDetails	S/P
ADT4	R2	Analysis of transactional data	Tagging transactions		S/P
ADT5	R2	Analysis of transactional data	The method that retrieves data about tagged transactions		P	The method that retrieves data about tagged transactions
ADT6	R2	Analysis of transactional data	Methods that retrieve structured data to the data model		P
ADT6	R2	Analysis of transactional data	The method that retrieves raw data from ASPSP		P
ADT7	R2	Analysis of transactional data	Methods for returning session status for downloading data enriched with KPI
Reporting PSD2Hub area: online portal containing reports from the LDS database
R1	1.0	PSD2Hub reporting	Access to online reporting views		S
R2	1.0	PSD2Hub reporting	Report view export to XLS format		S
R3	2.0	PSD2Hub reporting	API response time statistics e2e vs. request / response times from the ASPSS API		S
Handling exceptions area: portal response mechanisms PSD2Hub for exceptions and errors
OW1	2.0	Handling exceptions	A unique error ID	All methods	S/P	The identifier for each exception instance stored in the session and returned in the API response
SaaS Infrastructure area
SA1	1.0	SaaS	H/A configuration		S	Load balancer out of range - provided by TPP
SA2	1.0	SaaS	API Management Gateway		S	The service is based on Azure API Management
SA3	1.0	SaaS	Security Center		S
SA4	1.0	SaaS	Dedicated LDS database		P
SA5	1.0	SaaS	Dedicated database of logs (MongoDB)		S
SA6	1.0	SaaS	Support for containerization		S
SA7	1.0	SaaS			S
Infrastructure area: configuration on-premise
I1	1.0	Infrastructure	Cluster of application servers		S	Load balancer out of range - provided by TPP
I2	1.0	Infrastructure	Tool for viewing SB queues		S
I3	1.0	Infrastructure	API methods for handling the Load Balancer in the controlled shutdown of cluster nodes		S	Support for zero-downtime deployment
I4	1.0	Infrastructure	Cluster of middleware servers (SB cluster and MongoDB)		S
I5	1.0	Infrastructure	Diagnostic database MongoDB		S	Support for hiding sensitive data
I6	2.0	Infrastructure	Automatic deployment of version		S	Automatically display packages to an on-premise instance
I7	2.1	Infrastructure	Support for containerization		S
I8	1.0	Infrastructure	Configuration of logging into different targets (file, database etc.)		S	Powered by nlog
Agreement management area: support for the PSU-TPP consent cycle
ZZ1	2.0	Handling of contexts of requests for data by various processes - handling of goals.				Mechanisms are currently being developed/extended based on the next available implementations of the ASPSP API
ZZ2	2.0	Agreement life cycle management				Mechanisms are currently being developed/extended based on the next available implementations of the ASPSP API
ZZ1	2.0	Marking data for the desired purpose				Mechanisms are currently being developed/extended based on the next available implementations of the ASPSP API