Case Study · Insurance / Core Systems & Oracle Engineered Infrastructure
From twenty hours to forty-five minutes: keeping a multinational insurer’s core systems ahead of its business
A multinational insurer’s Egyptian end-of-day run had grown longer than the night it was meant to fit inside. Khwarizm has worked alongside the insurer since its first Oracle Exadata go-live — cutting end-of-day from more than 20 hours to 45 minutes, and standing up a regulator-mandated 31 December fiscal-year close in a two-month window.
An insurer’s day does not end when the branches close. Every policy issued, every premium collected and every claim settled has to be posted, reconciled and carried forward before the next morning’s business can begin, and the window for that work is fixed at both ends — by the hour the counters close and the hour they reopen. At a multinational insurer’s Egyptian operation, that nightly run had grown longer than the night. Khwarizm was brought in to make it fit again, and stayed.
When the night runs into the day
Insurance runs on batch. Underwriting, collections, commissions and reserving all settle overnight, and as a book grows the batch grows with it — quietly, for years, until the run that used to finish comfortably before dawn is still working when the first customer walks in. That is the point at which a technical measurement becomes a business one. Finance starts the day behind its own system. Reconciliations queue. Nobody can answer a question about yesterday until yesterday has finished closing.
The constraint was that nothing about the application itself was available to change. A core insurance platform is the system of record for a regulated business: it cannot be rewritten to run faster, and it cannot be taken down while the answer is worked out. Every hour recovered had to come from the infrastructure beneath it and from the way the workload was executed — not from asking the business to run something different.
The first Exadata
Khwarizm took the insurer live on its first Oracle Exadata, its move onto engineered infrastructure. Engineered hardware on its own does not fix a batch that has outgrown its window; it changes what is possible, and the rest is work. The gain came from analysing what the end-of-day run actually spent its time on, reshaping how that work was executed against the new platform, and sizing the platform from the measured workload rather than from the size of the database.
The nightly run now completes in 45 minutes. The practical consequence is not the number but the margin around it: a slow night is absorbed instead of escalated, and the operational day begins with the previous one already closed.
A report nobody used to run
The same pattern showed up in reporting, where it is easier to see what a duration costs. Receivables reporting took the better part of an hour a run. A report that takes that long is a report you schedule, and a report you schedule is one you consult after the fact — it cannot be part of a conversation with a customer, a broker or a collections decision. It arrives as a record, not as an answer.
Tuned onto the new platform, the same reporting returns in 3 seconds. What changed was not the speed of a job but its category: collections staff query receivables while the phone call is still going. The report stopped being a monthly artefact and became something people use.
Staying ahead of the book
The engagement did not end at go-live, and that is most of the story. A platform sized correctly for a growing insurer stops being correctly sized on a schedule nobody controls. Khwarizm has worked with the insurer’s team as a standing partner since 2013: performance analysis and tuning of the core application, database and application upgrades, and patching run as a maintenance cadence rather than as a project that has to be justified each time.
As the book grew, the Exadata storage was expanded ahead of capacity becoming the constraint, and a newer-generation platform was later sized and supplied on the same principle applied at the first go-live: measure the workload the application actually produces, then buy for that. The discipline is unglamorous and it is what keeps a core system from arriving at the next crisis without headroom.
Two months to close a year
In 2024 the Financial Regulatory Authority moved the whole Egyptian insurance sector’s fiscal year to run from 1 January to 31 December. For every insurer in the market that meant closing a fiscal year on a date its systems had never closed one on, to a deadline set by a regulator rather than by an IT plan.
The reported minimum for the functional testing alone was six months. This insurer had two. Khwarizm worked with its finance and IT teams to prepare, test and run the changed close on the core system inside that window, and the year closed on the regulator’s date without an extension. The margin came from knowing the platform already — a partner who has been tuning, patching and upgrading the same system for years does not spend the first month of a two-month window learning it.
The results
None of this is visible to one of the insurer’s policyholders, which is the point. A claim is settled, a premium is receipted, a broker gets an answer while still on the call — and the machinery that makes those things ordinary finished its work overnight, quietly, before anyone arrived to notice whether it had.