Two models
Entitlements that drift apart.
A right changed in one platform and not another is a security gap or a support call. Synchronize from one system of record and check it.
Portal strategy
One portal across retail,business and treasury.
Large banks often run separate platforms for retail, small business and commercial treasury. A portal in the login flow puts the bank's experience in front of them and gives business customers one place to start, on one authentication and entitlements model.
Why a portal
Why banks put a portal in front of their platforms.
One relationship can include an owner's personal accounts, a growing company and a treasurer approving wires. Without a portal, each platform's vendor decides what that customer sees first.
- 01Control of the experienceThe bank's navigation, brand and journeys in front, whichever platform does the work.
- 02Lightweight transactionsBalances, approvals, transfers, positive pay decisions, card controls and statements, without opening the full treasury platform.
- 03One journey across platformsRetail, small business and commercial accounts behind one sign-in.
- 04Moving up to treasuryA growing business moves to commercial treasury without a new login, new users or lost history.
- 05Mobile approvalsApprovers release payments from a phone under the same controls as the desktop.
- 06A foundation for APIsThe identities and entitlements that run the portal also decide what a customer's software, or a consented third party, can reach.
What the research says
Corporate digital platforms and identity are near the top of banks' priorities.
54%
of North American banks rank corporate digital banking platforms a top business priority, well ahead of any other.
Celent, Corporate Banking IT Pressures and Priorities, 202537%
rank digital identity management a top technology priority, second only to AI.
Celent, Corporate Banking IT Pressures and Priorities, 2025Risk-based
The FFIEC expects business customers' authentication to strengthen with risk, with controls on administrators and dual control.
FFIEC authentication guidance, 2021How Ignite supports you
We start with the entitlements model, which the rest depends on.
We've mapped entitlements between digital and treasury platforms on many digital conversions. We bring that to a portal program and deliver the integration behind it.
01
Strategy
Pattern, segments and sequence, matched to your platforms and their roadmaps.
02
The entitlements model
One model across platforms, its system of record, and the mapping to each one.
03
The integration
Single sign-on, step-up, platform APIs and the data the portal needs, built and tested.
04
The moves
Customers moved between platforms behind the portal, reconciled to the user and the right.
It starts with entitlements
A portal depends on one entitlements model across the platforms behind it.
Each platform defines a company, user, role and limit its own way. The program reconciles them into one model and names the system of record for each piece.
Identity
One sign-in
The bank's identity provider in front, with single sign-on into each platform.
Step-up once
Strong authentication at the portal that the platforms trust, so customers aren't challenged twice.
Shared sessions
No second login between the portal and a platform, and one timeout for both.
Entitlements
A common model
Companies, users, roles, accounts, functions, limits and approvals, defined once and mapped to each platform.
A system of record
One place owns each entitlement, and the platforms are kept in step from it.
One set of dual-control rules
The same approval rules whether a payment starts in the portal, the treasury platform or an API.
Administration
One place to manage users
A company administrator sets a user's rights and limits once, and each platform follows.
One view for the bank
Support and operations see a customer's access across platforms on one screen.
An audit trail
Each change to access, who made it and when, across platforms.
Portal patterns
Three portal patterns, from a launch pad to a full front end.
Banks usually start with the first and move on as the entitlements model matures, taking more control of the experience and more of the integration with each step.
1. The launch pad
In the portal
Sign-in, a summary across platforms, and single sign-on into each one.
In the platforms
Everything else, in each vendor's own experience.
What it takes
Single sign-on, an account summary feed, and a shared view of who the customer is.
2. The light layer
In the portal
Everyday tasks: balances, approvals, transfers, positive pay decisions, alerts and statements.
In the platforms
Complex work, by deep link: payment files, templates, liquidity, reporting and administration.
What it takes
Platform APIs for each light transaction, and an entitlements model the portal can enforce itself.
3. The front end
In the portal
The whole experience, designed by the bank, for all segments.
In the platforms
Processing engines behind APIs, replaceable without the customer noticing.
What it takes
Rich APIs on each platform, a mature entitlements system of record, and a permanent product team.
Open banking and APIs
The same entitlements model supports open banking APIs.
An open banking API needs what the portal already knows: who the user is, which accounts they may see and what they may do. With rationalized entitlements, the bank answers once, for the portal, its corporate APIs and consented third parties.
What the portal gives the API program
- One identity for each customer and user, across platforms
- Account-level rights that a consent can be checked against
- Company administrators who can see and revoke what's shared
What the API program adds
- Consent records, tokens and their expiry
- Standard data models, such as the FDX API
- Access for recipients outside the bank, with their own controls
The CFPB's Section 1033 rule covers consumer accounts only and doesn't require this for business customers. They ask for it anyway for accounting and ERP connections, and the FDX standard covers business data.
Beyond the build
A portal program needs governance across the lines of business.
Different teams own the platforms behind the portal, and the program has to bring them together.
Product ownership
One owner for the portal across retail, small business and commercial, with a roadmap each line of business can see.
Entitlements governance
Who may change the model, how a new platform's rights are mapped, and who resolves conflicts.
Segment rules
When a customer counts as small business or commercial, and what triggers a move.
Vendor contracts
Single sign-on, API access, embedding and data rights in each platform agreement before it renews.
Security and fraud
Session, device and step-up policy for the portal, and fraud monitoring across platforms.
Servicing
Support teams trained on one view of the customer, with procedures for problems that cross platforms.
Customer communication
Administrators told what's changing, when, and what to do, well before their login changes.
Rollout
Segments in waves, simplest platforms first, with a way back for each wave.
Measurement
Adoption, task completion and support calls by segment, as evidence for the next step.
What catches teams out
Where portal programs run into trouble.
Most portal problems occur where one system hands over to another.
Double challenges
Customers asked to step up twice.
A platform that doesn't trust the portal's authentication asks again. Agree what each platform trusts before the design is set.
Vendor limits
Not every platform can be fronted.
Some expose few APIs, restrict embedding or price access separately. Know each platform's limits before choosing a pattern.
Deep links
Links that miss the task.
A deep link that lands on a platform's home page instead of the task breaks the single journey.
One more platform
A portal the bank doesn't own.
Without the bank's own entitlements and APIs, the portal is one more vendor platform to convert one day.
Conversions underneath
Plan the portal around platform changes.
A platform due for replacement next year changes which pattern makes sense this year.
Spend 30 minutes with us
Talk with us about your portal program.
No pitch, no obligation. And if we're not the right team for it, we'll tell you that too.