The two documents
One BRD services existing policyholders; the other sells new ones. Both are Life Protection & Savings (Takaful) only — nothing here touches Property & Casualty. See Gaps.
Life – Online Services
A self-service portal for policyholders who already own a Life P&S policy — every request is OTP-gated and generates a tracked reference number.
- Inquiries — fund value/performance, outstanding payments, payment history, claim status, Zakat
- Money movement — surrender, partial withdrawal, top-up + top-up withdrawal, payment holiday, outstanding rescheduling
- Change requests — payment method, IBAN, billing day, fund switch/redirect, sum assured, add-ons, beneficiaries
- Claims — add-on coverage (TPD etc.), death coverage
- KYC refresh
Life P&S – Insurance Products
The bigger of the two: re-platforms new-business sales onto a new core insurance system across four channels for eight products.
- 8 products — Personal P&S, Kids P&S, Personal P&S Level Loaded, Kids P&S Level Loaded, Single Premium, Term Insurance, Pension (Retirement), Single Premium Pension (Retirement)
- 4 channels — Website, Mobile App, Aggregators, ARB Bank's Mubasher app
- Own risk register — the doc already ships 10 issues, 8 risks, 10 dependencies, scored
- Extras — contribution/fintech calculators, corporate affinity discount, quote retrieval, product comparison, underwriter workflow
Products in scope
All 8 products named in Doc 2's scope (§3), each with its own full purchase journey (§5.2.1–5.2.8). The variable that actually drives build effort isn't the product name — it's premium timing and charge structure.
| Product | Segment | Premium | Charge structure | Doc ref |
|---|---|---|---|---|
| Personal Protection & Savings Plan | Adult, individual | Regular | Front- or Level-Loadedcustomer's choice below the contribution threshold | §5.2.1 |
| Kids Protection & Savings Plan | Child, parent-owned | Regular | Front- or Level-Loadedsame threshold rule as Personal | §5.2.2 |
| Personal P&S Level Loaded Plan | Adult, individual | Regular | Level-Loadedmandatory above the contribution threshold | §5.2.3 |
| Kids P&S Level Loaded Plan | Child, parent-owned | Regular | Level-Loadedmandatory above the contribution threshold | §5.2.4 |
| Single Premium Product | Adult, individual | Singleone-time lump sum | N/A — no recurring charge structure to choose | §5.2.5 |
| Term Insurance Policy | Adult, individual | Regular | Pure protection — no savings component, TPD add-on only | §5.2.6 |
| Pension ProductRetirement | Adult, individual | Regular | Accumulation phase → pension payout phase | §5.2.7 |
| Single Premium PensionRetirement | Adult, individual | Singleone-time lump sum | Accumulation phase → pension payout phase | §5.2.8 |
Why this split matters for effort
Doc 2 §5.1.9 already routes Personal and Kids P&S by contribution value: above a configurable annual threshold (example given: 36K SAR), the customer is pushed straight to the Level-Loaded quotation with no choice offered; below it, the system shows a comparison and lets them pick. That branch — not the product name — is what the premium-calculation logic actually needs to handle, which is why Effort & timeline treats the 4 P&S variants as one build with a pricing-tier switch, not four separate builds.
The purchase journey
Every one of the 8 products in Doc 2 runs the same five-stage skeleton — only the middle content changes. That repetition is good news for delivery: build the skeleton once, configure it per product.
Integration map
Nineteen distinct external or cross-team dependencies across the two documents, grouped by what they do. Severity reflects how much of the journey breaks if that system is late, flaky, or unavailable — not how hard the API itself is to call.
| System | Used for | Named in | Risk if it slips |
|---|---|---|---|
| YakeenGov't identity registry | NID/Iqama + mobile match on every login and OTP trigger | Both docs | high |
| New core insurance system | Pricing, illustration tables, medical rules, policy issuance | Doc 2 | high |
| AML / KYC / blacklist screening | Sanctions check during onboarding; flags route to manual review | Doc 2 | high |
| CIAM | Customer login, session, and profile retrieval | Doc 2 | high |
| IBAN validationEMKAN Bank (Doc 1) vs. Neo Tek (Doc 2) — two different vendors named | Real-time bank/account validation before any refund or debit | Both docs | high |
| Payment gateway | Mada, Visa, Mastercard, Apple Pay, SADAD, STC Pay + EMI/BNPL (Tamara, Tabby) | Both docs | high |
| SPLSaudi Post / address service | Auto-fetch customer address after NID validation | Doc 2 | medium |
| Salary information service | Auto-populate income for underwriting limits | Doc 2 | medium |
| ERP | Receipts, VAT invoicing, refund settlement, reconciliation | Both docs | medium |
| ARB Bundle Engine | Cross-sell pricing/eligibility with bank products (mortgage, cards) | Doc 2 | medium |
| ARB Mubasher API exposure | Rate, Quotation, Policy Purchase, Payment APIs for the bank's app | Doc 2 | medium |
| ARCAl Rajhi Capital | Live fund allocation, performance, and unit value for policy servicing | Doc 2 | medium |
| Redis & Kafka | Data streaming for CRM/marketing triggers | Doc 2 | medium |
| Lemnisk | SMS/email campaign orchestration, behaviour tracking | Doc 2 | low |
| ART OTP/SMS system | OTP generation, delivery, masked storage, resend/lockout limits | Both docs | medium |
| Chatbot / WhatsApp | Service-status tracking and FAQ across web + app | Doc 1 | low |
| Partner / aggregator APIs | Secured RESTful distribution for external portals | Doc 2 | low |
| Underwriting queue | Manual accept / reject / request-docs workflow off the back of medical answers | Both docs | medium |
| B2E channel | Same after-sales services surfaced to internal/employee-facing tools | Doc 1 | low |
Finance & reinsurance — integrate, don't build
Short answer to "do we need to develop this ourselves": no, for Finance. And reinsurance isn't in either document at all — which is worth confirming rather than assuming.
Finance
Both BRDs treat Finance as a downstream system, never a module to build. Doc 2's own requirement #17 scopes it as ERP integration only — receipt generation, VAT invoicing, and reconciliation all happen inside the ERP, triggered by this platform, not recreated in it. Doc 1's cancellation flow follows the same pattern on the servicing side: the digital layer submits the request and a reference number, an existing Underwriting Refund Team validates it, and an existing Finance team settles the payout to the customer's IBAN within an SLA — none of that ledger or settlement logic gets rebuilt here.
Reinsurance
Neither document mentions reinsurance once — no treaty terms, cession rules, retention limits, or reinsurer-facing API. That's consistent with it sitting in core-system/actuarial territory rather than being a digital-channel concern: Doc 2's own Assumption #2 expects product rules and pricing to arrive "finalized... either within the core system or through connected systems like iFoundry" before this team integrates. The one place reinsurance could still surface without being named is the hard-coded coverage caps already in the Business Rules tables — Term Insurance's 50,000–499,999 SAR band, Pension's 50K–2.5M — which plausibly reflect an upstream treaty's retention limit. Worth a direct confirmation with the core-system/actuarial team rather than assuming those caps are arbitrary.
Complexity read
Relative sizing across the dimensions that actually drive schedule risk, not raw feature count. Scored against the scope described in both documents.
Net read
The UI itself is the easy part — both documents specify screens, fields, and error states in enough detail to build from directly. The real cost lives in the dependency graph: nine systems sit in the critical path of a single policy purchase (Yakeen → AML → core system → payment → ERP), and every one of them has to be live, fast, and correct in the same test window before UAT can start. Sequence integration testing around that chain first; treat the UI as the last thing that gets hard.
Saudi-specific friction
Points that don't show up in a generic insurance-platform build — specific to operating a Takaful product under Saudi regulation.
SAMA + audit trail
Doc 2 flags SAMA alignment as a live risk. Every service action across both documents needs a timestamped audit log — that's a cross-cutting requirement, not a feature to schedule separately.
Zakat, not just interest
Zakat is computed per unit at 2.5%/year on fund value and must be logged for religious compliance — a calculation with no conventional-insurance equivalent, and its own negative-scenario coverage in Doc 1.
Level-loaded vs. front-loaded
Doc 2's product-list logic branches customers between these two charge structures based on contribution size — a Takaful-specific distinction the UI has to explain, not just apply.
Yakeen is load-bearing everywhere
Login, onboarding, and every claim in both documents route through Yakeen. It's a national government service outside ART's control — no fallback is described anywhere in either BRD.
Two IBAN validators, one product line
Doc 1 names EMKAN Bank for IBAN checks; Doc 2 names Neo Tek. Same validation, same customer base, different vendor — needs reconciling before either team builds against it.
Arabic-first, not Arabic-added
Both documents require full Arabic/English parity across every screen and notification — RTL layout, transliterated fields, and dual-language SMS/email templates from day one, not a post-launch localisation pass.
Gaps & open questions
What's missing before this can be scoped with confidence.
Protection & Savings — fully covered, on scope
Confirmed: the ask was Life + P&S (Protection & Savings), and that's exactly what both documents deliver. P&S is the industry label for a Life policy that bundles a death/disability benefit with an investment-linked savings component — every product in Doc 2, and everything Doc 1 services after issuance, is a P&S policy. No separate Property & Casualty (motor/property/travel) scope was intended, so there's no missing document here — both PDFs are complete for what was requested.
IBAN vendor needs a decision
Confirm whether EMKAN Bank or Neo Tek is the system of record for IBAN validation before either the servicing team or the new-business team starts integration work — building against both wastes effort either way.
Core system timeline gates everything
Doc 2's own dependency table already names this as the top blocker. Worth getting a hard commitment on core-system API availability before committing a delivery date for new business — the servicing BRD (Doc 1) is comparatively decoupled and could move independently.
Effort & timeline to build this
Sized for the full scope of both documents, all four channels — Website, Mobile App, Aggregators, and ARB Bank's Mubasher app — assuming the core insurance system and third-party vendors (Yakeen, AML, IBAN, payment gateway) expose working APIs on the dates this project needs them. That assumption is the biggest lever on both numbers below, more than tooling choice.
Roughly 40% less raw engineering effort, but only 25–30% shorter calendar time — the gap between those two numbers is the point. Effort drops hardest wherever the BRDs already specify a screen field-by-field (the two documents are unusually implementation-ready — that's exactly what Claude reads fastest). Calendar time doesn't drop as far, because it's gated by things no amount of AI-assisted coding speeds up: the other team's core-system readiness, Yakeen/AML/bank vendor onboarding, SAMA and Shariah-board sign-off, and human UAT cycles.
| Workstream | Manual (person-days) | Claude-assisted (person-days) | Why |
|---|---|---|---|
| Solution architecture & API contracts | 45 | 25 | Claude drafts contracts/specs fast; architect still owns the decisions |
| Core system integration | 280 | 180 | Gated by the other team's release schedule regardless of tooling |
| Identity & compliance stackYakeen, AML, CIAM, KYC | 140 | 90 | Vendor onboarding/approval is a fixed external timeline |
| Payment orchestration7 methods + BNPL/EMI + STP tiers | 115 | 60 | Highly patterned branching logic — scaffolds well |
| New-business journeys8 products × 4 channels | 325 | 150 | Best fit for AI: one 5-stage skeleton repeated 8 times, fields fully specified |
| After-sales servicing15+ modules × Web/App/B2E | 220 | 110 | Same repeatable pattern as new-business screens |
| Underwriting workflow | 70 | 45 | Business logic is clear; queue/case-management UI scaffolds fast |
| ARB Bank API exposure + bundle engine | 90 | 55 | Partner security review stays a manual gate either way |
| NotificationsOTP, chatbot, WhatsApp | 55 | 30 | |
| ERP / VAT / reconciliation | 55 | 35 | |
| UI/UX designbilingual, RTL | 90 | 55 | Claude drafts the component system; a designer still refines it |
| QA — SIT / UAT / security / performance | 225 | 160 | Test-case generation accelerates; execution & sign-off don't |
| PM / BA / coordination overhead | 160 | 120 | Shrinks with team size, not with code-gen speed |
Where the estimate could move
These numbers assume both channels' worth of after-sales servicing and all 8 new-business products ship together. If you phase it — Doc 1 (after-sales) first, since it's the more decoupled of the two, then Doc 2 product-by-product — the calendar timeline stretches but the peak team size and burn rate drop, which is usually the safer sequencing given the core-system dependency flagged in Complexity read.