BRAVURA SONATA · ANNU-INIT-001

Smart Discovery
UK Annuity Prospect

Source: POC Gaps & Issues Log · Opportunity Briefing v2 · 2025-11-20

Bravura Data Platform & MCP Infrastructure

Smart Discovery interrogates the Sonata codebase, Jira and Confluence in real time — surfacing gaps, epics and user stories that are grounded in what the platform actually does today, not what documentation says it does.

⟳ Live codebase analysis ⟳ Jira integration ⟳ Confluence context ✦ AI-accelerated discovery

Initiative

Initiative details Fields are editable

Initiative ID	ANNU-INIT-001✎ Edit
Initiative Title	Sonata UK Annuity – POC Gap Resolution & Readiness for Prospect Deployment✎ Edit
Strategic Driver	The prospect requires a policy administration system capable of supporting Individual Annuity products across three immediate books (~1.05 m policies). Bravura's Sonata platform demonstrated core capability during the October–November 2025 POC, but 16 gaps were identified that must be resolved before Day 1 go-live.✎ Edit
Business Value	Closing these gaps unblocks the prospect's ability to win three exclusive annuity books (300 k, 250 k, 500 k policies) and positions Bravura as the prospect's long-term annuity technology partner, with significant further pipeline in BPA, DC/DB and FCA-regulated business.✎ Edit
Scope	All 16 gaps identified in the Prospect POC Gaps & Issues document, grouped into six epics: Tax & PAYE Processing; Payment Processing; Payroll & Statutory Reporting; UI & Screen Improvements; Compliance & Lifecycle Processes; and Analysis & Discovery.✎ Edit
Out of Scope	Day 2 integrations (Proof of Life, AML/KYC, agent portal). Customer self-service portal. Data migration. Infrastructure / hosting.✎ Edit
Key Stakeholders	Prospect: TBC · Bravura: TBC✎ Edit
Target Delivery	Day 1 gaps resolved prior to first client go-live (Q1/Q2 2026). Discovery items to be scoped within Sprint 1–2.✎ Edit

Enrich the initiative with documents and context before generating

Epics & User Stories

Tax & PAYE Processing

Resolve all defects related to PAYE tax code display, tax table population, tax refund calculation and arrears date handling for UK Individual Annuity products. These issues are blockers for accurate daily payroll runs required by all three prospect books.

▾

E1-S1 Display Tax Details field on non-SIPP Annuity accounts ▾

Gap:Gap #1 Priority:Critical — Day 1 blocker Effort:S

User Story

As a Sonata configuration user / administrator,

I want the Tax Details field to appear on the Account tab in Account Maintenance for UK Annuity product types

so that I can view, insert and alter the tax code linked to an annuity account without requiring a manual back-end database update.

Acceptance Criteria

AC1The Tax Details drop-down is visible on the Account tab for the UK Annuity (UKAN) product type without any database intervention.
AC2Selecting a tax code from the drop-down correctly persists the association to the account.
AC3Existing behaviour for SIPP (SIPT) accounts is unchanged.
AC4The fix is driven by product configuration (product type / behaviour) rather than hard-coded SIPT logic.

Notes / Dependencies

Current workaround: aclk_sipp_type_code_id manually updated in DB. Root cause is a hard-coded check for SIPT. Fix must be agreed with dev team as to whether it is a behaviour flag or product type extension.

E1-S2 Fix PAYE table population and prevent spurious future-tax-year records ▾

Gap:Gap #3 Priority:Critical — Day 1 blocker Effort:M

E1-S3 Correct tax refund calculation on PAYE annuity transactions ▾

Gap:Gap #4 Priority:Critical — Day 1 blocker Effort:M

E1-S4 Validate and fix payment reversals with PAYE tax refund ▾

Gap:Gap #5 Priority:High Effort:S

E1-S5 Determine and validate correct tax date for arrears transactions ▾

Gap:Gap #8 Priority:High Effort:M

Payment Processing

Fix defects preventing annuity payments from being saved, processed and run as part of batch payroll. These are Day 1 blockers: The prospect requires daily payroll runs for up to 365 days per year across all three books.

▾

E2-S1 Resolve save error in Pension Payment History for annuity accounts ▾

Gap:Gap #2 Priority:Critical — Day 1 blocker Effort:M

User Story

As a Sonata annuity administrator,

I want to enter and save next payment date and amount in the Pension Payment History tab for a UK Annuity account

so that the account can be moved to Active status and regular payment schedules can be established.

Acceptance Criteria

AC1Payment details (next payment date, regular amount) can be entered and saved on Pension Payment History without error for the UKAN product type.
AC2Account status can be progressed to Active after saving payment details.
AC3Tax Free Portion and Taxable Untaxable Portion fields are editable (not disabled) once account reaches the appropriate status.
AC4Cash receipt (initialisation step) is still required per existing workflow and is not broken.

Notes / Dependencies

Linked to BASE-292259 / BASE-292255. Lisa found a partial workaround but status progression to Active remains blocked. Root cause investigation required.

E2-S2 Fix Pension Payment Process to execute for non-SIPP annuity product types ▾

Gap:Gap #15 Priority:Critical — Day 1 blocker Effort:M

E2-S3 Fix 'Run All' batch payroll to include UK Annuity product types ▾

Gap:Gap #16 Priority:Critical — Day 1 blocker Effort:S

Payroll & Statutory Reporting

Extend payslip generation and HMRC Full Payment Submission (FPS) to cover annuity-specific transaction types, and build the CT61 report required for Purchased Life Annuity (PLA) products. Mandatory for HMRC RTI compliance.

▾

E3-S1 Include NI annuity payment transaction types in payslip generation ▾

Gap:Gap #6 Priority:High — Day 1 blocker for NI members Effort:S

User Story

As a Sonata payroll administrator,

I want payslips to be automatically triggered and correctly populated for Regular Pension Payment NI (NIRP) and Regular Pension Payment NI Arrears (RPAP) transaction types, including reversals

so that members receiving NI-tax-coded annuity payments receive accurate payslips and the document record is complete.

Acceptance Criteria

AC1Payslip is generated for NIRP transactions (same trigger logic as existing regular pension payment types).
AC2Payslip is generated for RPAP (arrears NI) transactions.
AC3Reversal of either NIRP or RPAP within the defined period also triggers a payslip.
AC4Payslip dataset is updated to pull the correct values for NIRP and RPAP transactions.
AC5Existing payslip trigger logic for SIPP/UK standard transaction types is not broken.

Notes / Dependencies

Enhancement to selection criteria and dataset; not a new payslip template. Reversals must be included in both trigger logic and dataset query.

E3-S2 Extend FPS job to include annuity NI transaction types and correct field logic ▾

Gap:Gap #7 Priority:Critical — HMRC compliance Effort:L

E3-S3 Build CT61 report for Purchased Life Annuity (PLA) products ▾

Gap:Gap #13 Priority:High — Day 1 for PLA products Effort:M

UI & Screen Improvements

Remove Australian-specific fields from UK Annuity screens to reduce confusion for the prospect's UK administration team and align with the 'configure not customise' principle agreed with the prospect.

▾

Compliance & Lifecycle Processes

Implement the Certificate of Existence process — a regulatory requirement for annuity providers to confirm members are still living before continuing payments. This process does not currently exist in Sonata for UK annuity products.

▾

Analysis & Discovery

Three gaps could not be sized during the POC due to insufficient requirements. Discovery spikes are required to understand scope, confirm technical approach and produce estimates before backlog items can be created.

▾

E6-S1 Spike: Define requirements and estimate effort for With Profits annuity support ▾

Gap:Gap #10 Priority:Medium Effort:Spike 2–3d

User Story

As a Bravura solution architect / prospect product owner,

I want a documented set of requirements and a high-level technical approach for supporting With Profits (asset-backed / reviewable income rate) annuity products in Sonata

so that the team can size and plan the necessary development work and include it in the delivery roadmap.

Acceptance Criteria

AC1Requirements workshop held with the prospect to capture With Profits income rate review process, valuation triggers, and data flows.
AC2Technical spike output: written assessment of what Sonata can handle today vs what requires development.
AC3Estimate (T-shirt or story points) produced for any development work required.
AC4Decision made whether With Profits support is required for Day 1 (Books 1 & 2 have 2–4% asset-backed policies).

Notes / Dependencies

Book 3 has no asset-backed policies. Day 1 priority to be confirmed with the prospect based on whether the three target books include live With Profits policies from inception.

E6-S2 Spike: Define requirements and estimate effort for Fixed Term Annuity maturity processing ▾

Gap:Gap #11 Priority:Medium — Book 3: 7% Fixed Term Effort:Spike 1–2d

E6-S3 Spike: Identify and catalogue outstanding back-office processes for annuity administration ▾

Gap:Gap #12 Priority:Medium Effort:Spike 2–3d

✦

Coming soon

Once additional context has been captured across stories, AI-assisted revision will rewrite acceptance criteria and user story wording to reflect the latest decisions and constraints.

Business Process Analysis

Source — Prospect Process Library

158 processes across 32 domains, drawn from the prospect's Benefit Studio process list. Domains are grouped into five functional areas. Use this view to cross-reference operational processes against the gap backlog and identify Day 1 coverage obligations.

158Total Processes

32Domains

5Functional Areas

⌕ ✕

Summary – Backlog at a Glance

Story ID	Epic	Title	Gap Ref	Priority	Effort
E1-S1	E1 Tax	Tax Details field on non-SIPP Annuity accounts	Gap #1	Critical	S
E1-S2	E1 Tax	PAYE table population & spurious future-year records	Gap #3	Critical	M
E1-S3	E1 Tax	Correct tax refund calculation on PAYE transactions	Gap #4	Critical	M
E1-S4	E1 Tax	Payment reversals with PAYE tax refund	Gap #5	High	S
E1-S5	E1 Tax	Correct tax date for arrears transactions	Gap #8	High	M
E2-S1	E2 Pmt	Save error in Pension Payment History	Gap #2	Critical	M
E2-S2	E2 Pmt	Pension Payment Process for non-SIPP product types	Gap #15	Critical	M
E2-S3	E2 Pmt	'Run All' batch payroll picks up UK Annuity	Gap #16	Critical	S
E3-S1	E3 Rpt	NI transaction types in payslip generation	Gap #6	High	S
E3-S2	E3 Rpt	FPS job – annuity NI transaction types & field logic	Gap #7	Critical	L
E3-S3	E3 Rpt	CT61 report for PLA products	Gap #13	High	M
E4-S1	E4 UI	Hide Australia-specific fields from UK screens	Gap #9	Medium	S
E5-S1	E5 Cmp	Certificate of Existence letter process	Gap #14	High	M
E6-S1	E6 Disc	Spike: With Profits annuity requirements	Gap #10	Medium	Spike
E6-S2	E6 Disc	Spike: Fixed Term maturity processing requirements	Gap #11	Medium	Spike
E6-S3	E6 Disc	Spike: Back-office process catalogue	Gap #12	Medium	Spike

PI Planning View

◷

Delivery window

Define a start date and number of planning intervals to configure the timeline below.

ProgrammeAnnuity Gap Resolution

Total Duration20 weeks

PIs2 × 10 weeks

Sprints10 × 2 weeks

StartApr 2026

Stories16 (incl. 3 spikes)

PI-2026-01 Foundations, Critical Blockers & Tax Accuracy Apr 07 – Jun 12, 2026

PI 1 Objectives

1All discovery spikes complete — With Profits, Fixed Term maturity and back-office process gaps scoped, estimated and backlog items raised for PI 2 planning.

2Core payment engine unblocked — Pension Payment History saves correctly, Pension Payment Process runs for UKAN, and 'Run All' batch covers annuity products.

3PAYE tax accuracy delivered — tax code display, table population, refund calculations and arrears date handling all correct and regression-tested.

4Payslip foundations in place — NI transaction types (NIRP/RPAP) trigger payslip generation correctly ahead of FPS work in PI 2.

Sprint 1 · Weeks 1–2

Foundations & Discovery

Apr 07 – Apr 18

"Unblock the basics; understand the unknowns."

7 / 10 pts

E1-S1 S

Display Tax Details field on non-SIPP accounts

E1 — Tax & PAYE

E2-S3 S

'Run All' batch payroll picks up UK Annuity

E2 — Payment Processing

E6-S1 Spike

Spike: With Profits annuity requirements

E6 — Discovery

E6-S2 Spike

Spike: Fixed Term maturity processing

E6 — Discovery

E6-S3 Spike

Spike: Back-office process catalogue

E6 — Discovery

Sprint 2 · Weeks 3–4

Core Payment Engine

Apr 22 – May 02

"Get payments saving, running, and processing."

9 / 10 pts

E2-S1 M

Resolve save error in Pension Payment History

E2 — Payment Processing

E2-S2 M

Fix Pension Payment Process for non-SIPP types

E2 — Payment Processing

E1-S2 M

Fix PAYE table population & spurious future-year records

E1 — Tax & PAYE

⚠ Requires E1-S1 ✓

Sprint 3 · Weeks 5–6

Tax Accuracy & Payslip Foundations

May 06 – May 16

"Make tax calculations correct; lay reporting groundwork."

8 / 10 pts

E1-S3 M

Correct tax refund calculation on PAYE transactions

E1 — Tax & PAYE

⚠ Requires E1-S2 ✓

E3-S1 S

NI transaction types in payslip generation

E3 — Payroll & Reporting

E4-S1 S

Hide Australia-specific fields from UK screens

E4 — UI

Sprint 4 · Weeks 7–8

Dependent Tax Fixes

May 20 – May 30

"Complete the tax chain; nail arrears and reversals."

8 / 10 pts

E1-S4 S

Validate & fix payment reversals with PAYE refund

E1 — Tax & PAYE

⚠ Requires E1-S3 ✓

E1-S5 M

Correct tax date for arrears transactions

E1 — Tax & PAYE

Sprint 5 · Weeks 9–10

PI 1 Hardening & System Demo

Jun 03 – Jun 13

"Regression clean, demo-ready, PI 2 backlog refined."

5 / 10 pts

REGR —

Regression — payment & PAYE tax chain (PI 1 scope)

Quality Gate

DEMO —

PI 1 System Demo with prospect stakeholders

Ceremony

I&A —

Inspect & Adapt — refine PI 2 backlog with spike outputs

Ceremony

PI-2026-02 Compliance, Statutory Reporting & Go-Live Readiness Jun 16 – Aug 21, 2026

PI 2 Objectives

1HMRC RTI compliance achieved — FPS job fully extended for annuity NI transaction types; all field-level logic compliant and tested against HMRC environment.

2Regulatory lifecycle processes delivered — Certificate of Existence batch letter process live; CT61 report available for PLA products.

3Spike output stories resolved — net-new stories from PI 1 discovery (With Profits, Fixed Term maturity, back-office processes) delivered or formally de-scoped.

4Full system UAT complete — The prospect signs off all Day 1 capability; go-live readiness confirmed for first client book.

Sprint 6 · Weeks 1–2

FPS & Compliance Build

Jun 16 – Jun 27

"Tackle the large FPS job; begin compliance obligations."

9 / 10 pts

E3-S2 L

Extend FPS job — annuity NI transaction types & field logic

E3 — Payroll & Reporting

⚠ Requires E3-S1 ✓

E5-S1 M

Certificate of Existence letter process

E5 — Compliance

Sprint 7 · Weeks 3–4

Statutory Reports & Spike Outputs

Jun 30 – Jul 11

"Close out reporting obligations; action spike findings."

8 / 10 pts

E3-S3 M

Build CT61 report for PLA products

E3 — Payroll & Reporting

TBD-1 TBD

Stories from E6-S1 With Profits spike output

E6 — Discovery output

TBD-2 TBD

Stories from E6-S2 Fixed Term maturity spike output

E6 — Discovery output

Sprint 8 · Weeks 5–6

Back-Office Processes & Buffer

Jul 14 – Jul 25

"Fill process gaps; absorb any carry-over from Sprint 7."

7 / 10 pts

TBD-3 TBD

Mandatory back-office process gaps from E6-S3 catalogue

E6 — Discovery output

BUF —

Carry-over buffer & defect fix capacity

Risk Reserve

Sprint 9 · Weeks 7–8

Full System Regression

Jul 28 – Aug 08

"End-to-end regression across SIPP and all UKAN paths."

6 / 10 pts

REGR —

Full regression — all UKAN & SIPP payment, tax and reporting paths

Quality Gate

HMRC —

FPS end-to-end test against HMRC test environment

Quality Gate

PERF —

Performance baseline — batch payroll at volume (500 k policies)

Quality Gate

Sprint 10 · Weeks 9–10

UAT & Go-Live Readiness

Aug 11 – Aug 21

"Prospect signs off; Day 1 cleared for first client book."

5 / 10 pts

UAT —

UAT with the prospect — full Day 1 scenario pack

Quality Gate

SIGN —

Prospect formal sign-off & go-live approval

Milestone

DEMO —

PI 2 System Demo & Inspect & Adapt

Ceremony

Critical — Day 1 blocker

High priority

Medium priority

Spike / Discovery output (TBD)

Quality Gate / Ceremony (not a story)

⚠ Dependency badge = must-complete prerequisite

Key Dependencies

→E1-S1 must complete before E1-S2 — Tax Details field must be displayable before PAYE table population can be fully tested.
→E1-S2 must complete before E1-S3 — correct PAYE table state is a prerequisite for validating refund calculations.
→E1-S3 must complete before E1-S4 — reversal testing is explicitly blocked until the underlying refund calculation is correct (per Gap #5 commentary).
→E3-S1 (PI 1, Sprint 3) must complete before E3-S2 (PI 2, Sprint 6) — payslip NI transaction logic informs and is shared with the FPS job enhancements.
→E6 spikes (PI 1, Sprint 1) must complete before TBD-1/2/3 can be backlog-refined and scheduled into PI 2 Sprints 7–8 — spike outputs feed directly into PI 2 planning.

Generated from Prospect POC Gaps & Issues Log and Opportunity Briefing v2 Bravura Solutions (UK) Limited — Confidential

Smart DiscoveryUK Annuity Prospect

Smart Discovery
UK Annuity Prospect