Release - 20/06/2020

Release Overview

This release enhances the functionality of the core Tapico Platform. Introducing the segregation of Service Pack (API Products) through publication and authorisation. Cleaning up user management so it is managed from a central location. Structural changes to the response shape of the Open Finance API to support a variety of end-user scenarios. Advisors/Portfolio Manager as authenticating users not just end-investors.

Breaking Changes

Pagination – Switched from Offset to Cursor based pagination.

Changed pagination behaviour of API. Skip/take query parameters have been removed in favour of cursor/limit. Response payload returns optional nextCursor instead of totalResults. All endpoints are affected by this.

New entity hierarchy structure – AuthorisingUser → Customers → Accounts → Transaction, Balance, Beneficiary.

The following endpoints have been replaced:

  • GET /accounts/… → GET /authorising-users/{authorisingUserId}/accounts/…
  • GET /customers/… → GET /authorising-users/{authorisingUserId}/customers/…

GET /account-access-consents – Parameter Query Changes:

  • accountServicer → accountServiceId
  • application → applicationId
  • customer → authorisingUserId
  • externalCustomerId → REMOVED
  • consentStatus → status

New Features

The following features have been released:

Service Pack Publication:

  • Organisations that create and maintain API products on the Tapico Platform do so via entities called “Service Packs”.
  • Organisations can now control who can use their Service Pack(s) by deliberately granting access, via “publishing”, the Service Pack(s) to a select 3rd party Organisation(s). That 3rd party Organisation(s) can in turn connect the Service Pack to an Application that they manage on the Tapico Platform.

Service Pack Subscription Authorization:

  • The connection between an Application and a Service Pack(s), referred to as a “Subscription”, has to be approved by the Organisation that manages that Service Pack.
  • Subscriptions can be approved or rejected by the central authorisations page.

User Management:

  • Users can no longer be permissioned directly against an Application.
  • All user management is now centralised around the Organisation. User’s can become “Members” of one or more Organisations. The permissions they have against a particular Organisation (Owner, Read Write, Read Only) drive the actions the user can apply to ALL the entities (Upstreams, Service Packs, Applications) under an Organisation.

API Structural Changes:

  • authorising-users
    • The authorising-user and customers are two separate entities in the Universal API. Which can facilitate scenarios where the ‘customer’ is not the authenticating user. For example, the authenticating user is an Advisor or a Portfolio Manager that covers multiple customers and accounts.
  • account-groups
    • There is an option to flag Accounts as belonging to a particular group. What that group represents is flexible. Possible examples include, portfolios, investment mandates, family groups.