KORTEKSData · Analysis · Delivery

Industries

Where a wrong number is a finding.

We concentrate on financial institutions because the constraints are specific: core systems that cannot be taken offline, figures that carry legal weight, and a supervisor entitled to ask how any of them was produced.

Start a conversation What we do

Banking

Sector 01

Banking

Core extraction, credit data, and reporting that reconciles to the ledger.

The core banking system is usually the oldest thing in the building and the least safe to disturb. We read from it carefully, land the data somewhere it can be governed, and rebuild reporting on that instead of on a chain of spreadsheets that one person maintains.

Credit and supervisory figures then have a traceable path from a general ledger account to a submitted line — which is the question an examiner asks first.

  • Typical workCore and payments extraction, credit data marts, supervisory and management reporting, branch and channel analytics.
  • Common triggerA reporting deadline that is met by overtime, or a finding about data quality in an audit.

Insurance

Sector 02

Insurance

Policy, claims and finance joined into one set of numbers.

Policy administration, claims handling and the general ledger usually grew separately, so actuarial work starts with a reconciliation exercise nobody budgeted for. We build the joined model once, with the reconciliation automated and monitored.

Pricing and reserving then work from the same figures the accounts do, and a change in one is explainable in the other.

  • Typical workPolicy and claims data models, actuarial data preparation, reserving and pricing inputs, portfolio and loss-ratio reporting.
  • Common triggerActuarial and finance disagreeing on the same figure, or a migration off a legacy policy system.

Markets

Sector 03

Capital markets

Reference data kept clean, positions that arrive on time and match.

Instrument and counterparty reference data decays quietly, and the cost shows up later as a break in a valuation nobody can explain. We treat reference data as a managed asset: sourced, versioned, and checked before it is used.

End-of-day processing gets the same treatment — a schedule with alerts, a reconciliation, and a named owner for each break.

  • Typical workInstrument and counterparty reference data, end-of-day position and valuation feeds, break reporting and reconciliation.
  • Common triggerA late or unexplained end-of-day run, or onboarding a new asset class into existing systems.

Fintech

Sector 04

Fintech

Controls put in before the first regulatory review, not after it.

Fast-growing teams tend to have good engineering and no data governance, which works until a licence application, a bank partnership or a due diligence asks for evidence. We add the missing layer without slowing the product down.

That means lineage, access control and model documentation that fit how your team already works — and reporting that scales past the founder's dashboard.

  • Typical workAnalytics foundations, regulatory and partner reporting, fraud and risk scoring, model governance for a first audit.
  • Common triggerA licence application, a bank partner questionnaire, or investor due diligence on data.

Evidence

What a reviewer asks for, and where it comes from.

Frameworks differ by market and by licence — IFRS 9, Solvency II, DORA, GDPR and local supervisory reporting all ask variations of the same four questions. We build the answers into the platform rather than assembling them under deadline.

  1. Question

    Where did this number come from?

    Column-level lineage from the submitted figure back to the source record, held in the catalog rather than in a diagram that is out of date.

    Built in: lineage and catalog

  2. Question

    Who can see and change it?

    Role-based access recorded against systems and datasets, with changes logged and reviewable without asking an engineer.

    Built in: access model and audit trail

  3. Question

    How do you know it is right?

    Quality rules and reconciliations that run on every load, with failures raised to a named owner instead of discovered at reporting time.

    Built in: quality checks and alerting

Next step

Bring us the awkward one.

The report that is always late, the migration nobody wants to own, the model that has been in pilot for a year. Tell us the short version.