Reinsurance Client Portal
One governed place for your ceding companies and their brokers. Contracts and signing status, data calls, documents, and claims visibility, each scoped to the treaties that client is on, with every system of record staying exactly where it is.
Book a demo
What it is
A reinsurance client portal is the workspace a reinsurer gives the ceding companies it writes for. The DICEUS Reinsurance Client Portal puts contracts, data calls, documents, submissions, and claims in one place, with access tied to the specific treaty or program each person is entitled to view.
It is in front of the systems you already use rather than replacing any of them. Your document repository remains the system of record. Your core, claims, and submission systems keep doing what they do. The portal governs who reaches them and shows your clients where everything stands.
Who it is for
- Reinsurers with assumed business
- Composite reinsurers
- Mutual reinsurance organizations
- Insurance groups with assumed operations
- Heads of reinsurance
- Client relations teams
- Contracts and operations teams
- Technology and enterprise applications
What this replaces
The work that costs a reinsurance team its week is rarely underwriting. It is the coordination around the client relationship.
-
01
Access managed folder by folder
Permissions live in the document system, and nobody can say with confidence who sees what.
-
02
Contract status lives nowhere
Where a treaty is in review, redline, and signature is a question someone answers by asking.
-
03
Redlines move by email
Versions circulate as attachments, and the current one is whichever arrived most recently.
-
04
Data calls run on a spreadsheet
Someone updates it weekly and sends it round, and status is only ever as fresh as that.
-
05
Infrequent users miss their work
A client contact who signs in twice a year has no way of knowing something is waiting.
-
06
Brokers see too much or too little
A separate site per broker, maintained by hand, with no simple way to scope by placement.
What your clients see
Contracts
Every treaty they are on, and where each one currently stands.
- Program and contract records
- Current stage and key dates
- Document versions, redline and final
- Signature progress to fully executed
- Scoped to their own programs
Submissions
New business and renewal submissions, with what is due when.
- Open submissions and status
- Guided submission form
- Supporting documents attached
- Calendar of upcoming deadlines
Data calls
What you have asked them for, and how far it has got.
- Requested data and due date
- Expected formats and templates
- Upload with validation
- Progress through to approval
Documents
The same folder structure they already know, now inside the portal.
- Folder tree and file list
- Version history per document
- Preview, download, open in source
- Who uploaded it and when
Messages and tasks
Conversation and tasks attached to the thing they are about.
- Threads on a contract or submission
- Tasks with a named owner
- Reassignment to a colleague
- Notification preferences per person
Claims
A read‑only summary of the claims under their treaties.
- Claim overview and status
- Responding policies
- Loss information
- Audit trail
- Read‑only, no claim filing
Facultative
Special acceptance risks submitted and then tracked in one place.
- Risk description and program
- Sum insured and requested cession
- Supporting documents
- Status through to bound or declined
Find the right solution for your needs
What you control
-
Who is assigned to each client
Every client relationship has a named team on your side, held in an editable matrix rather than in someone’s memory. Account executive, client relations, contracts, actuarial, claims. A role can hold more than one name, or be marked open with interim cover, and changes are staged and visible before they take effect.
-
Access by treaty
Entitlements attach to a specific treaty or program. Someone who works on one program cannot reach another, including by following a direct link, because the scoping is enforced on the data rather than applied to a folder afterwards.
-
Permissions with guardrails
You create roles and assign permissions inside the scope each role is allowed to have, so a broker cannot be given underwriting access by mistake. A person can hold several roles, and you see the combined effect before you save it.
-
Everything is logged
Sign‑ins, views, submissions, role changes, and exports are recorded with the person, the action, and the account it touched. The log is searchable and exportable by date range, user, and treaty, which is what an internal audit or a client review actually asks for.
-
Identity you already use
Sign‑on runs through your existing identity provider, with a fallback route for participants who are not federated with you. Nobody maintains a second set of credentials.
-
Users come and go cleanly
Accounts for client contacts, broker staff, and your own people are managed in one place, with activation and deactivation recorded rather than inferred from a folder permission someone forgot to remove.
Contracts and signing
The contract cycle is where most client frustration sits, because it is long, it involves lawyers, and nobody outside the process can see it. The portal gives both sides the same view of where every treaty stands, from first draft through to fully executed, without anyone sending a status email.
The program view
- Contracts by program and client
- Counts by stage at a glance
- What is overdue or not started
- Average time through the cycle
The contract record
- Type, dates, and reporting frequency
- Layers, limits, and attachment points
- Linked submissions, data calls, claims
- Named account executive
Getting to signature
- Version history, redline and final
- Configurable stages to execution
- Handoff to your e‑signature service
- Signed copy filed automatically
Data calls
Catastrophe and non‑catastrophe work run as separate tracks, because one goes through modeling and the other goes straight to pricing.
-
01The request goes out
The annual request is raised per client and program, with the expected formats, the templates, and the due date attached to it.
-
02Your client submits
They upload against the template in the portal. Files are checked as they arrive, and anything that fails can be accepted deliberately rather than silently.
-
03It moves through review
Controls, then modeling or pricing depending on the track, then approval. Status is derived from the dates that have been filled in, not typed by hand.
-
04The output goes back
The result is published to the client, and where a broker is on that placement it becomes visible to them at the same time.
Broker access
Reinsurance brokers get their own scoped view of the portal. Access is hierarchical, from the firm down to the office and the individual, and each broker organization is separated from the others at the data layer rather than by keeping them on different sites.
A broker sees the placements they are actually on and the output that has been shared with them, and nothing else. Not your other clients, not the programs they do not place, not claims, not data calls that have not been released.
What stays where it is
- Your document repository
- Your core system
- Your claims system
- Your submission portals
- Your identity provider
- Your reporting tools
- Your accounting system
- Your email
- Your folder structure
- Your naming conventions
- Your approval chains
Deployment
Each client runs on a dedicated instance, with access segregated by organization and treaty inside the application rather than only at the perimeter. The platform is deployed on‑premises, in the cloud, or as a hybrid of the two. The model is agreed during scoping and depends on your infrastructure, data residency, and IT requirements.
How a rollout runs
A first working release typically lands in six to eight weeks, with the full agreed scope following over four to eight months. Exact timelines are agreed upfront.
-
Discovery
We map your client structure, your programs, your personas, and the access model you need, and agree what the first release covers.
-
Configuration
Roles, per‑treaty access, contract workflows, and the data‑call pipelines are configured against that map rather than built from scratch.
-
Integration
Your document repository, your identity provider, and your e‑signature service are connected, with your IT and security teams involved from the start.
-
Go live
User acceptance testing, training for your team and your clients, then production and hypercare while people move off email.
How this compares
Most reinsurers already have somewhere to put files and a way to share them. The question is what that arrangement cannot do.
Why DICEUS
-
Insurance and reinsurance is the only domain we build software for
-
Integration experience with core insurance systems
-
Access scoped by treaty, built in rather than configured on
-
Deployment on‑premises, in the cloud, or hybrid
-
A reinsurance financial platform beside it, if you need one
See the portal running against your own programs, your brokers, and your data‑call cycle.
Book a demo
Frequently asked questions
Do we have to move off our document system?
No. It stays the system of record and the portal surfaces it, so your clients see the folder structure they already know. Nothing is migrated, and files keep living where they live today.
Is this a core system?
No. It is in front of whatever core, claims, and submission systems you run and governs access to them. If you need a reinsurance financial platform as well, that is a separate product.
How do we control who sees what?
Entitlements attach to a specific treaty or program rather than to a folder, and they are enforced on the data. You build roles inside permitted scopes, assign more than one where needed, and see the combined effect before saving.
Can brokers only see their own placements?
Yes. Broker access is hierarchical from firm to office to individual, each broker organization is separated at the data layer, and a broker sees only the placements they are on and the output released to them.
Does it handle invoicing and settlement?
Not today. Accounting, invoicing, settlement, and reconciliation are a later phase and are not part of what is described on this page. Ask us where that sits on the roadmap if it matters to your decision.
How long until something is working?
A first functional release typically lands in six to eight weeks, with the full agreed scope following over four to eight months. The exact timeline is agreed upfront and depends on the integrations in scope.
Will our clients actually use it?
That is the real risk, and it is why rollout includes training for your clients as well as your team. The portal is built around the documents and cycles they already recognize rather than a new way of working.
What happens to our existing portals?
They stay. Placement, claims submission, and any other transactional portal keeps its job, and this sits in front as the governed way in rather than replacing any of them.
