Policyholder master & conduct

Conduct evidence, not a conduct dashboard.

Complaints that record root cause, TCF outcome, whether they were upheld and the redress paid — on a customer master carrying vulnerability, KYC and AML as structured fields rather than notes.

app.aegisnow.ai/console

Customer 360 Workspace

Live

Customers on master

2.1M

Households grouped

914K

Open complaints

142

-31

Upheld with redress

38

Complaint resolution within SLA, last 12 weeks

Trend

AegisNow Customer 360 is a policyholder master and conduct record. Complaints carry root cause, treating-customers-fairly outcome, upheld status, redress amount, regulator escalation and days to resolve — so "what is generating complaints across this book" is an aggregation rather than a reading exercise. The customer record holds vulnerable-customer status, KYC state and an AML flag as first-class fields, alongside segment, tenure, lifetime value, NPS, a household identifier and a primary producer. Stated plainly: there is no identity resolution, no lapse or surrender model, no market-conduct dashboard and no policy-to-customer link — the relationship groupings exist, but the book does not yet hang off them.

0facts on every complaint: cause, outcome, upheld, redress, escalation, days

Illustrative outcome. We will map Customer 360 to your own data, frameworks and targets in a working demo.

Why teams choose it

The case for Customer 360

One view of every policyholder, household and interaction.

Upheld is not the same as resolved

A resolved complaint says the queue is clear. An upheld one with a root cause and a redress figure says the customer was right, what went wrong, and what it cost.

Root cause as a field, not a narrative

Because it is structured, "what is generating complaints across this book" is answerable by aggregation instead of by reading every case.

Vulnerability is a conduct obligation

It sits on the master record as a structured flag, not as a note in one department's file, so it reaches every subsequent touch.

One record for commerce and conduct

Segment, tenure, lifetime value and NPS sit beside KYC state and AML flag — so the two views of a customer cannot hold different opinions.

Direction on every interaction

An inbound complaint and an outbound retention call are different events; a history that flattens them tells you less than the rows it holds.

Limits on the page, not in the demo

No golden record, no lapse model, no conduct dashboard — named here rather than discovered during an evaluation.

Inside the module

Capabilities that ship on day one

Every capability runs on the shared data fabric, the governed Cortex brain and the evidence ledger — so Customer 360 compounds with the rest of the platform.

Capability detail

What each capability actually does

Each section below is directly linkable, so a specific answer can be cited on its own rather than buried in a page.

Capability 01

Complaints with a fairness outcome, not just a status

Root cause, TCF outcome, whether it was upheld, redress paid and days to resolve — on every complaint.

A complaint record holds what a conduct regulator asks for rather than what a ticketing system needs. Alongside category, severity, status and the narrative, it carries the root cause, the treating-customers-fairly outcome, whether the complaint was upheld, the redress amount paid, whether it was escalated to a regulator, and the days it took to resolve.

The distinction that matters is between upheld and resolved. A resolved complaint tells you the queue is clear. An upheld complaint with a root cause and a redress figure tells you the customer was right, what went wrong and what it cost — which is the only version of the data that supports a conduct review or a root-cause programme.

Because root cause is a field rather than free text buried in a narrative, the question "what is generating complaints across this book" is answerable by aggregation instead of by reading. That is the difference between complaint handling and complaint learning.

What it does

  • Record root cause, TCF outcome, upheld status and redress amount on every complaint.
  • Track regulator escalation as its own fact rather than inferring it from severity.
  • Measure days to resolution per complaint.
  • Aggregate by root cause, so the pattern across a book is a query rather than a reading exercise.
  • Distinguish a resolved complaint from an upheld one.

Implements

  • Treating Customers Fairly (TCF) outcomes
  • Root-cause classification
  • Regulator escalation and redress tracking

See it in the product

Open a complaint: it names the root cause, the TCF outcome, whether it was upheld, the redress paid and the days it took — not simply an open or closed flag.

Capability 02

Vulnerability, KYC and AML on the customer record

Vulnerable-customer status, KYC state and AML flag are first-class fields, not notes someone wrote.

The customer record carries a vulnerable-customer flag, a KYC status and an AML flag as structured fields. This matters because each of them changes how the customer must be treated, and a treatment obligation recorded as a note in a free-text field is one that will be missed by whoever handles the next interaction.

Vulnerability in particular is a conduct obligation rather than a service preference. Holding it on the master record — rather than on a single interaction, or in one department's spreadsheet — is what makes it available to every subsequent touch.

Segment, status, tenure, lifetime value and NPS sit alongside them, so the commercial view and the conduct view of a customer are the same record rather than two systems with different opinions.

What it does

  • Hold vulnerable-customer status as a structured flag on the master record.
  • Carry KYC status and an AML flag as first-class fields.
  • Keep segment, status, tenure, lifetime value and NPS on the same record.
  • Mask tax identifiers at rest rather than storing them in the clear.

Implements

  • Vulnerable customer identification
  • KYC status and AML flagging
  • Tax identifier masking

See it in the product

Open a customer: vulnerability, KYC state and AML flag are fields you can filter and report on, and the tax identifier is stored masked.

Capability 03

Interaction history with channel, direction and sentiment

Every recorded touch carries how it arrived, which way it went, and how it read.

Interactions are recorded with their channel, direction (inbound or outbound), category, subject, a summary, a sentiment reading, the agent who handled it, its status, an SLA target in hours and when it occurred. Direction is worth calling out: an inbound complaint and an outbound retention call are different events, and a timeline that flattens them tells you less than the rows it contains.

The SLA target sits on the interaction, so responsiveness is a property of each touch rather than an average computed later over a population.

Stated honestly: this is an interaction log against the customer, not a unified timeline across the estate. Interactions do not reference a policy or a claim — there is no such column — so the chronological view is of contacts, not of contacts interleaved with the policy and claim events they were about. The previous version of this page claimed the latter.

What it does

  • Record channel, direction, category, subject, summary and sentiment on each interaction.
  • Attribute each interaction to the agent who handled it.
  • Carry an SLA target in hours on the interaction itself.
  • Order the customer's contact history by when it occurred.

Implements

  • Inbound / outbound direction
  • Per-interaction SLA target

See it in the product

Open a customer's interactions: each row shows the channel, the direction, the sentiment and the SLA target. Then note the limit — no row references the policy or claim it concerned.

Capability 04

Household and producer grouping

Customers carry a household identifier and a primary producer, so a relationship is groupable.

The customer record carries a household identifier and a primary producer reference, which is what allows customers to be grouped into a relationship rather than viewed only one at a time. Household is the grain most retention and coverage-gap questions are actually asked at.

The producer reference means a customer can be attributed to the person who serves them, which is the join a conduct question — "do complaints cluster around a producer" — depends on.

The honest limit is the same one distribution has: the grouping keys exist, but the book does not yet hang off them. Because no policy records its customer or its producer, household relationship value and producer-level conduct clustering are groupings waiting for data rather than views you can open today.

What it does

  • Carry a household identifier on the customer, so customers group into a relationship.
  • Reference a primary producer from the customer record.
  • Support grouping and filtering by household and by producer.

Implements

  • Household grouping key
  • Primary producer attribution

See it in the product

Group customers by household identifier and the relationship is assembled. Ask for its total in-force premium and the honest answer is that policies do not yet reference their customer.

Capability 05

Where this module ends today

Stated rather than implied: the golden record, the retention model and the conduct dashboards are not built.

This page claimed identity resolution into a golden record across admin, claims and billing; a unified timeline spanning policies, claims and payments; AI lapse and surrender scoring with next-best-action prompts; market-conduct dashboards with replacement monitoring and exam-ready evidence packs; consent records with privacy request handling; and AI-suggested service responses. None of those exist.

Specifically: there is no identity-resolution or de-duplication code for customers, and no foreign key from a policy or a claim to a customer — the only tables referencing the customer master are its own complaints and interactions. There is no lapse, surrender or churn model of any kind; the propensity scoring in the codebase is `lossPropensity` in property rating, which is an underwriting factor and unrelated. Market conduct exists as the string "MarketConductExam" in a validator enum. Consent is a single marketing boolean, not a consent record with a lawful basis and a privacy request workflow.

The customer figures on the record — policyCount, premiumInForce — are stored rather than derived, and do not reconcile with the book: they sum to 39 policies against 274 that actually exist. That is the same defect class as the stored SLA status and the seeded fraud score elsewhere in this platform, and it is recorded here rather than presented as a 360-degree view.

What it does

  • Name the absent capabilities rather than omitting them from the page.
  • Identify the policy-to-customer link as the dependency the relationship views wait on.

Implements

  • Capability disclosure

See it in the product

Nothing to demonstrate, which is the point — this exists so the gaps are found here rather than during an evaluation.

Built for the people who own the risk

Made for your team, aligned to your frameworks.

Cortex skill-agents draft the work, cite their sources and write every action to the evidence ledger — so Customer 360 accelerates the people accountable for it without putting your audit posture at risk.

Who it serves

  • Customer service leaders
  • Conduct & compliance teams
  • Retention & marketing teams
  • Complaints officers
  • Operations executives

Aligned to

  • FCA Consumer Duty / TCF
  • NAIC market conduct exams
  • GDPR / CCPA
  • State replacement regulations
  • Complaint-handling standards
CortexAI reasoning copilot
Grounded

Shared device fingerprint with the ring94
Repair shop tied to a prior SIU case87
Loss pattern matches the closed cluster81
SourcesPolicy ledgerClaims graphSIU casebook
Confidence94%
FAQ

Customer 360 FAQ

What evaluation teams want to know before a demo — answered plainly.

It records the things a review actually asks for: root cause, the treating-customers-fairly outcome, whether the complaint was upheld, the redress amount, whether it went to a regulator, and days to resolution. Upheld and resolved are held separately, because a cleared queue and a customer who was right are different facts.

No. There is no identity-resolution or de-duplication code for customers, and no foreign key from a policy or a claim to the customer master — the only tables referencing it are its own complaints and interactions. The previous version of this page described golden-record management across admin, claims and billing as shipped. What exists is a single customer master; consolidating other systems into it is unbuilt.

No. Interactions carry channel, direction, category, sentiment, agent, SLA target and time, but no reference to a policy or a claim — there is no such column. So it is a contact history, not contacts interleaved with the policy and claim events they concerned. The distinction is the difference between knowing you spoke to someone and knowing what about.

No. There is no lapse, surrender or churn model of any kind, and no next-best-action prompts. The only propensity scoring in the codebase is `lossPropensity` in property rating — an underwriting factor for occupancy, construction and protection class, entirely unrelated to customer retention. The page previously implied otherwise.

Not implemented. Market conduct exists in this codebase as the string "MarketConductExam" inside a validator enum — a label, not a capability. There are no conduct dashboards, no replacement monitoring and no exam-ready evidence packs. The complaints model above is genuine conduct evidence and is the foundation such monitoring would be built on, but it is not that monitoring.

As a single marketing boolean on the customer record. That is not a consent record: there is no lawful basis, no per-purpose or per-channel grain, no consent history and no privacy request workflow. A carrier with GDPR or state privacy obligations should treat this as a starting field rather than a compliance capability.

See Customer 360 on your data

Book a working session and we will map your sources, workflows and frameworks onto Customer 360 — and show Cortex reasoning over them live.

Customer 360 — One view of every policyholder, household and interaction. | AegisNow Insurance