Hi @Mridu,

I haven’t seen a clean blanket rule that holds across regulated BFSI, or across any domain, to be honest. 

In my experience, the accelerators do exactly what the name implies... they give you a solid, opinionated starting point (data model, blocking, features, MLflow, clustering, evaluation), but they’re not plug‑and‑play products. On every serious ER project, there has been a customer‑specific build on top, including bank‑specific survivorship rules, risk‑based thresholds, integration with their MDM/CRM/case systems, and governance/audit flows for compliance.

So I’d think of it less as a fixed percentage and more as... use the accelerator to get from 0 --> 1 quickly, then expect to invest in the last‑mile work that’s unique to your organisation and regulators. I’ve never been able to take an accelerator "as is" and industrialise it straight into production.

Since your question specifically relates to BFSI projects, I can share insights from my experience working with a couple of insurance clients, including one that was implementing a similar ER for regulatory reporting, known as sanctions regulations, where we had to ensure we didn't sell policies or conduct business with sanctioned individuals or organisations. We couldn't simply use accelerators "as is". Therefore, my advice would be... try not to alter the accelerator logic. Instead, treat it as a reference implementation and move all bank‑specific behaviours into configuration tables, policies, and workflow layers around it.

Hope this helps.