Platform setup models - Vendor vs Practice

Overview

There are two models for onboarding a software provider to the SISS Platform: Vendor and Practice.

The best model depends on how the provider’s software is built and how they intend to deploy Bank Feeds to their clients. This document explains both models, their respective trade-offs, and guides when to recommend each approach.

Comparison Summary

The Practice model

How it works

The software provider (FINTECH) is onboarded to the SISS Platform as a Practice. A Practice creates and manages any number of Clients underneath it. Each Client is a distinct entity - typically a unique ID used to represent one of the Practice's, or Fintech’s own end customers.

The FINTECH uses a single set of Practice credentials to access Bank Feed data. Transactions for all connected clients can be retrieved through the Practice-level API access, with FINTECH responsible for mapping the transactions to the appropriate Client within its own application.

The Practice Model: Entity Hierarchy

1. Practice (top level)

A Practice is the organisation using the platform. It holds a single set of API credentials, which are used to authenticate all activity for every Client it manages.

2. Client (created by the Practice)

Using its API credentials, a Practice creates and manages any number of Clients underneath it. Each Client is a distinct entity — typically a unique ID used to represent one of the Practice's own end customers.

3. Bank Feed (created by the Client)

Each Client can have one or more bank feeds connected to it. A bank feed belongs to exactly one Client.

The Key Rule: Data Isolation Between Clients

Because all Clients sit under one set of Practice-level credentials, the Practice is responsible for keeping Client data properly segregated. Specifically:

1. Each bank feed must only be accessible to the Client it's attached to.

2. Client A must never be able to view, query, or otherwise access Client B's bank feeds - even though both were created using the same Practice credentials.

3. This isolation is an obligation on the Practice, not something the platform enforces automatically at the credential level - since one credential set spans many Clients, correct scoping of every request (making sure it's tied to the right Client ID) sits with the Practice's own implementation.

Pros

• Simpler onboarding : FINTECH is onboarded once as a Practice, with no need to create and manage separate SISS credentials for each end client.

• Simpler integration — FINTECH can access its clients’ Bank Feed data through a single Practice-level integration and map the data internally to the appropriate Client.

• More scalable for cloud-based platforms — particularly where a centralised platform manages a large number of clients from a single application environment.

• Centralised management — FINTECH can manage Bank Feed connections and client mapping centrally within its own platform.

• Well suited to multi-client SaaS platforms — where clients are tenants or customers within a shared application environment.

Cons

• Data separation is the provider’s responsibility — FINTECH must ensure transactions and account data are correctly mapped to and isolated between Clients within its application.

• Greater reliance on application-level controls — SISS does not provide separate Practice-level credentials to enforce isolation between individual Clients.

• Not well suited to independent on-premise deployments — where each end client operates its own software instance, server, network, or database and requires strong separation between environments.

• Incorrect internal mapping can create data-access risks — because client-level separation is managed within FINTECH’s application rather than through separate SISS credentials.

Best for

The Vendor model

How it works

The software provider (e.g. FINTECH) is onboarded to the SISS Platform as a Vendor. The Vendor’s master credentials are used to create individual credentials for each Practice it onboards.

• FINTECH, as the Vendor, creates credentials for each Practice it onboards (e.g. Family Practice A, Family Practice B).

• Each Practice configures its system using the credentials created specifically for that Practice.

• API calls are made in the context of each Practice, with each Practice able to retrieve only the transactions belonging to its own connected accounts.

• Data separation is enforced at both the API and credential level, ensuring one Practice cannot access another Practice’s data.

The Vendor Model: Entity Hierarchy

1. Vendor (top level)
   A Vendor is the organisation at the top of this model. It creates Practices, but unlike the Practice model, it does not hold any shared credentials that reach down into their data.

2. Practice (created by the Vendor)
   Each Practice is created by the Vendor, and each one receives its own unique, independent set of API credentials at creation. These credentials belong to that Practice alone and are not shared with the Vendor or any other Practice.

3. Client (created by the Practice)
   Using its own unique credentials, a Practice creates and manages any number of Clients underneath it - the same as in the Practice model.

4. Bank Feed (created by the Client)
   Each Client can have one or more bank feeds connected to it, each belonging to exactly one Client.

The Key Rule: Data Separation Is Structural, Not Procedural

1. The Vendor cannot see a Practice's Clients, and cannot see any Client's bank feed data. It has no credential that grants it access to that layer at all.

2. Because each Practice's credentials are unique to it, there's no shared secret for a gap in process or implementation to leak across — separation between Practices is enforced by the architecture itself, not by each Practice remembering to scope its requests correctly.

3. The fintech building the integration is responsible for securely storing each Practice's unique credential set and using the correct one when making API calls on that Practice's behalf.

Pros

• Strong data separation: each Practice has its own credentials, with access enforced at the credential and API level rather than relying solely on the Vendor’s internal application logic.

• Works well with on-premises deployments: particularly where each Practice has its own separate software instance and environment.

• Suitable for independently operated Practices: each Practice can be configured and managed separately without sharing credentials or data with other Practices.

• Clear isolation between Practices: a Practice’s API access is limited to the accounts and data associated with that Practice.

Cons

• Higher onboarding overhead: the Vendor must create and manage separate credentials for each Practice it onboards.

• Credential management becomes a Vendor responsibility: the Vendor needs to ensure each Practice receives and configures the correct credentials.

• More complex at scale: as the number of Practices increases, managing individual credentials and configurations can become operationally burdensome.

• Separate API context per Practice: API access is established separately for each Practice, which can add complexity where a Vendor needs to manage or monitor many Practices.

Best for