Secure self-service for customers, brokers, intermediaries and business partners, built around the entitlement chain that decides who may see whose data and what they may do with it.
A customer signing into their own portal is a straightforward problem. They are one person, the data is theirs, and the only question is whether it is really them.
Access in a partner portal is not a permission on a user. It is a chain of relationships, and a break anywhere along it is a data exposure or an unauthorised instruction.
Entitlement is a permission on a user
Rather than a chain the portal walks on every request.
Partner staff changes never reach the bank
So revocation depends on somebody remembering to ask.
Self-service submits rather than completes
And the customer calls to ask where it went.
Information differs between channels
The portal, the statement and the agent disagree.
Document exchange is a file upload
With no provenance, retention or visibility rules.
Partner onboarding is a manual sequence
Measured in weeks, and the partner is choosing between banks.
There is no status anybody can see
Which is the single largest driver of contact.
Filtering is enforced in the interface
And the export, the search and the API are not.
Ask how you would learn that a broker’s employee left last month. Trace the actual mechanism. In most institutions the honest answer is that the firm is supposed to tell you, there is no process that checks, and the credential stays active until an annual review or an incident. That person may still be able to see client data and submit instructions. The fix is delegated administration plus recertification, it is a bounded piece of engineering, and the exposure in the meantime is one of the clearest on the estate.
Portal programmes usually begin with journeys and designs, because that is what stakeholders can react to. The relationship and entitlement model is then inferred from the screens, which is the wrong direction and is expensive to correct later.
The model is the foundation. Once it is right, most of the screens are straightforward, and a new partner type is configuration rather than a release.
Step 1
Identify every actor and the relationships between them
Step 2
Map the journeys each actor actually needs
Step 3
Design the entitlement model as data, not as roles
Step 4
Establish how each relationship change is learned
Step 5
Define the service requests in scope, end to end
Step 6
Design status as a first-class feature
Step 7
Design document exchange as a records capability
Step 8
Design identity, including federation where it fits
Step 9
Integrate with the systems that hold the truth
Step 10
Test entitlement adversarially, not only functionally
Step 11
Roll out by partner segment with support in place
Step 12
Monitor adoption, completion, turnaround and access hygiene
Count how much of your contact volume is somebody asking for a status. Pull the contact reason data for one partner or customer segment and separate the requests from the chasing. In most institutions chasing is a large share, it is entirely avoidable, and it is the cheapest thing a portal can remove, because it requires exposing state that already exists rather than automating anything. It is also the fastest adoption driver, because it is the thing partners notice in the first week.
Grouped by what each part is responsible for. The first group is the foundation and the one that decides whether the rest is safe.
Identity, access and onboarding
The entitlement chain modelled as data and enforced at the service layer on every request
Delegated administration, recertification and dormancy handling, as set out in section 3
Identity federation where a partner has its own identity provider, and credentials where it does not
Partner and intermediary onboarding, including the due diligence hand-off to your financial crime function
Firm, mandate and client relationship administration, held as relationships rather than flattened into roles
Service requests and workflow
Customer self-service for account servicing requests, with the retail banking channel itself covered on our Digital Banking Platforms page
Business and corporate banking access, including multi-user approval flows
Request intake and workflow orchestration across the systems that have to act
Case tracking with a state model the person waiting can understand
Notifications on state change, scoped so that a message never names something the recipient should not see
Document exchange
Secure document submission and retrieval, with provenance recorded: who, when, through which channel
Versioning and supersession, since a corrected document is a new record rather than an overwrite
Retention and disposition per data class, under your records policy
Visibility rules per document, which is a separate question from visibility of the case it belongs to
Visibility and reporting
Partner performance dashboards, built on metrics agreed contractually rather than chosen analytically
Pipeline and portfolio views scoped strictly to the firm’s own relationships
Service status and turnaround reporting, visible to both sides of the relationship
Reporting built against the same entitlement model as the interface, which is where portal exposures most often originate
The third column is the point of the table. These are usually scoped as portal features and each one is decided by something that is not a screen.
| Workload | Who uses it | What it actually turns on |
|---|---|---|
| Account servicing | Customers, directly | Whether the request can complete |
| Document submission | Customers and partners | Provenance, retention and visibility rules |
| Service requests | Both, continuously | A state model the waiting party understands |
| Corporate banking access | Several people per customer | Mandate and approval modelling |
| Lending partner collaboration | Brokers and the bank together | Case-level scoping across two organisations |
| Broker onboarding | The firm, then its staff | Due diligence hand-off and turnaround |
| Partner performance views | The firm and the bank | Metrics agreed in the agreement |
Portals accumulate data. A copy of customer details to render a page faster, a cached list of cases, a local status because the source system is slow, a document store because nobody could reach the real one in time.
Each of those is defensible individually and together they turn the portal into a store of customer and partner information sitting on the most exposed surface the institution runs. The architectural goal is a portal that reads and writes through to systems of record and keeps as little as it can.
An access layer that resolves the entitlement chain on every request, from the relationship data rather than from the session
Integration with core banking, lending, CRM and case management as the sources of truth, on the patterns described on our Banking Data Platform Engineering page
Identity federation and credential management, supporting a partner’s own identity provider where one exists
Workflow orchestration for requests that cross systems or need a person, with the state owned in one place
Document management using the institution’s records platform rather than a portal-local store, with provenance and retention carried
Notification infrastructure with scoping applied to the content, not only to the recipient
Observability including access-pattern monitoring, since unusual access by a partner user is a security signal this surface specifically needs
Request a record you are not entitled to see, outside the interface. Take a case or account identifier belonging to another firm or another customer and request it directly through the portal’s own service calls, then through its search, then through its export, then through any report. If any of those returns data, the entitlement rule is living in the screen. On a partner portal that is not a vulnerability finding, it is one partner seeing another partner’s client, and it is the single most important test to run before launch and after every release.
Which privacy, consent, data protection, outsourcing and consumer protection requirements apply, what a third party may be shown about a customer, and on what basis, are determined by your privacy, legal, compliance and conduct functions, based on your operating markets. We do not interpret those requirements and this page does not state which apply to you.
Technology supports a control framework. It does not independently establish one, and no platform makes a disclosure lawful.
Identity and access
- Authentication to the standard your security function sets, with the strength proportionate to what the user can do rather than uniform
- Entitlement derived from the relationship chain and enforced server side on every request, including search, export, reports and APIs
- Delegated administration with recertification, dormancy handling and single-action revocation of a whole firm
- Attribution, so every action records the individual who took it rather than the firm, which is why shared credentials are unacceptable
Consent and segregation
- What a partner may see about a customer established by your privacy and conduct functions, with the basis recorded rather than assumed from the relationship
- Consent and preference state enforced in the portal and in its notifications, not only recorded elsewhere
- Data segregation between firms designed and tested as a boundary, which on a shared platform is the control everything else depends on
- Minimisation of what is shown, so a partner sees what they need to service the case rather than the full customer record
Documents and records
- Provenance, classification, versioning and retention as described in section 6
- Secure handling of inbound files, including scanning and content validation at the boundary
- Disposition as a controlled act, since deletion is as much an obligation as retention
- Audit trails over submission, access, download and sharing of every document
Resilience and accessibility
- Availability objectives agreed per journey, recognising that a partner portal outage stops a sales channel rather than inconveniencing a user
- Dependency on a partner’s identity provider identified as an operational risk with a stated fallback
- Accessibility treated as a requirement, tested with assistive technology, which for a portal used by other businesses may also be a procurement condition they impose on you
- Audit trails over access, entitlement change, configuration and administrative action
Portal reporting leads with adoption, because logins are easy to count. A high login count with low completion describes a portal people check and then call about, which is more contact rather than less.
| Failure | How it presents |
|---|---|
| A leaver still has access | Nothing presents. That is the problem |
| Entitlement enforced in the screen only | Export or search returning more than the page |
| Adoption up, contact volume flat | A portal being visited and then phoned about |
| Requests submit and stall | Completion far below submission, chasing rising |
| A firm with three staff and one login | High activity per user, shared credential |
| Document rejections concentrated | One unclear requirement generating rework |
| Onboarding measured at the wrong stage | Fast portal setup, slow actual start |
| Partner metrics disputed | Definitions never agreed contractually |
The outcomes below follow from three choices: model the entitlement chain as data, make the partner maintain their own users, and treat status as the product where the request cannot complete.
Self-service that completes, measured to resolution, with the requests that cannot complete handled through visible status instead
Manual coordination reduced, particularly the email and telephone traffic that exists only to establish where something is
Partner interactions faster, measured from first contact to first submitted case rather than at the setup step
Visibility on both sides of the relationship, from shared facts rather than from separate reports
An access position that is current, because the people who know about staff changes are the ones maintaining the register
Document exchange that produces records rather than files
A platform where a new partner type is configuration rather than a release
We will take one portal and establish four things: whether entitlement is enforced on the request or the screen, how a relationship change is actually learned, how much contact is pure chasing, and what customer data the portal is holding that it does not need. You get the findings whether or not we build anything.
CaliberFocus builds customer and partner portals where the entitlement chain is modelled explicitly and enforced on every request, the partner maintains their own users, and the status of every request is visible without anybody calling to ask. We treat document exchange as a records obligation and keep the portal itself holding as little data as possible.
- Entitlement enforced at the service layer, including search, export and APIs
- Delegated administration with recertification and single-action revocation
- Request status designed as the product where a request cannot complete
- Documents captured as records with provenance, versioning and retention
Security & Compliance
