Enter your keyword

PSD2hub

First PSD2 API in Poland!

We propose our services and technology solutions in order to help Bank leverage the business opportunities provided by new payment directive PSD2. Our proposal is composed by several elements.

Our proposed approach

  • Our banqware platform as a PSD2 integration hub
  • Development of the data connectors to selected banks in order to provide API integration as soon as it will be possible
  • Our change management process aiming to rapidly react on new APIs exposed by banks (including ongoing monitoring of changes and proactive approach – early adopters, sandbox access, hackathons etc.)
  • Our support in defining and implementation of the multibanking functions in Bank web and mobile apps through API provided by the hub
  • Project management as well as required functional and business consultancy
  • Supporting Bank for production deployment
  • Spectrum of value added functions available for the next steps - data analytics on transactional data, widgets, non-banking data aggregation on others available on banqware now and planed on our development roadmap

Our platform banqware is a technology solution providing the end-to-end multibanking digital experience for the Customer. Platform can be integrated and embedded within existing bank IT landscape in different variants and configurations

Our platform

  • end-2-end solution, including our frontend layer (white labeled)
  • set of elements extending the existing digital banking solution of the bank, including our widgets to be embedded and SSO integrated standalone service
  • our data integration and backend solution providing data access and business logic via API
  • integration layer that loads retrieved data into existing bank data model.
psd2hubArchitecture

banqware platform generic architecture

banqware platform is composed by the following components:

Financial data connectors

  • Open Bank Project, Figo – providing plug and play gateways for PSD2 API to be exposed by banks. All the banks implementing those standards will be automatically integrated with our platform.
  • Screen scraping data providers: Eurobits, Kreditech.
  • Other banking API, including our end-end integration with solarisBank A.G. (account opening, KYC, aggregation, payments, card operations etc.).

Data integration data connectors

Abstract layer for data retrieved from different sources. Information provided by connectors is unified to one single format. Processes are orchestrated by our service bus.

Source agnostic data layer

Local database providing permanent storage for data. This layer allows the applications, built on top of the hub, to access data in asynchronous way in online (data request will trigger the data sync from source connector) and offline mode (data layer will respond with last known state of the information).

Analytical engine

Set of value added services, including:

  • Data enrichment and tagging/categorization,
  • Metrics, forecasting.

Those services provide ready-to-use inputs for PFM/BFM applications.

Data lake

Dedicated data lake (event based) DB that stores:

  • full request lifecycle identifiable by unique key:
    • beginning with cookies and other diagnostic details,
    • method calls with parameters,
    • possible exceptions with call stack and all the possible info,
    • response,
  • behavioral data (frontend interactions).

Service layer

set of APIs for integration of external apps with a hub.

API gateway

single point of interoperability used for managing, monitoring and provisioning the APIs exposed by the hub (*):

  • Self-service API key management,
  • Auto-generated API catalog, documentation, and code samples,
  • OAuth-enabled API console for exploring APIs without writing a line of code,
  • Secure APIs with key, JSON Web Token (JWT) validation, and IP filtering,
  • Protect APIs from overload and overuse with quotas and rate limits,
  • Response caching for improved latency and scale,
  • Near real-time usage, performance and health analytics

(*) On-premise implementation of API gateway can have different set of functions and capabilities.

Frontend layer

Our digital banking frontend for individual and SME customers with rich set of widgets (Detailed specification of the frontend is presented in the separated documentation available on request)

Our platform as PSD2 Hub for Bank

  • Data connectors will support screen scraping based account data aggregation for selected top banks
  • PSD2 ready connector will be delivered as a generic for working with requested banks via API those banks will expose. This generic connector will be used as a baseline for rapid implementation of country- specific APIs once those will be exposed in test mode as well as customized connectors for banks outside of country standard.
  • Optionally, there will be a dedicated PSD2 connector for BANK data (utilizing the API exposed by BANK to TPP).
  • All aggregated information will be stored in banqware local data storage (LDS) in unified format and structure. As an option this information can be directly propagated to BANK data model (without storing in LDS)
  • PSD2Hub will expose the set of APIs (described H/L in the next section of this document) that will be used by BANK apps.
  • PSD2Hub will manage the Customer consents and provide the set of APIs for consent management in external BANK apps (e.g. listing active consents in web banking, user profile/setting section).
  • PSD2Hub will offer all the APIs through the single point of interoperability (API gateway).
  • As an option hub will provide a data analytics module.