KORTEKSData · Analysis · Delivery

Services

What we are hired to do.

Four practices, one delivery model. Each one below lists what is included, what you end up owning, and how a typical engagement is staffed — so you can price the conversation before you have it.

Start a conversation Industries we serve

Data

Practice 01

Data management

The platform and the rules that make people trust what comes out of it.

Most reporting problems are not reporting problems. They are ingestion that silently drops rows, a definition of "active customer" that two departments disagree on, or a table nobody can name an owner for. We fix the layer underneath before we build anything on top of it.

We work with the platform you already pay for where that is sensible, and say so plainly when it is not. Migrations are planned as increments with a reconciliation step at each one, so the old and new systems can be compared while both are still running.

  • ArchitectureWarehouse or lakehouse design on cloud or on-premise, sized to your volumes and your retention obligations.
  • IngestionBatch and streaming pipelines from core banking, payments, policy administration, CRM and third-party feeds.
  • QualityData contracts, validation rules, reconciliation to source, and alerts that reach a named person.
  • GovernanceBusiness glossary, catalog, column-level lineage, retention policy and role-based access.
  • MigrationIncrement plans, parallel runs, cutover runbooks and rollback criteria agreed in advance.
You getA running platform, its pipelines, tests, documentation and access model — in your repositories.
Typical teamData architect, two data engineers, business analyst, part-time delivery manager.
First milestoneOne domain end-to-end, reconciled to source, in six to ten weeks.

Analysis

Practice 02

Business analysis

The translation layer between a regulation, a process and a backlog.

A requirement that says "the report must comply" is not buildable. Our analysts sit with the people who do the work, read the actual circular or policy, and produce a specification an engineer can estimate and a reviewer can sign.

The output is written down and kept current — not held in one person's head. When the engagement ends, your team can change the system without calling us.

  • DiscoveryProcess mapping, system inventory, and interviews with the people who work around the gaps today.
  • DefinitionsA single agreed meaning for each metric, dimension and status code, signed off by the business owner.
  • SpecificationSource-to-target mappings, transformation rules, edge cases and acceptance criteria.
  • ValidationTest scenarios written from the specification, and user acceptance run with real users.
  • HandoverDocumentation your team maintains, plus the walkthrough sessions to make that realistic.
You getA specification set, a definitions register and a test pack — all in your document system.
Typical teamLead analyst plus one analyst; a data modeller when the target is a warehouse.
First milestoneA mapped process and an agreed definitions register in three to five weeks.

Delivery

Practice 03

Project & delivery management

One person accountable for the date, the vendors and the bad news.

Software programmes in financial institutions rarely fail on technology. They fail on a dependency nobody tracked, a vendor whose contract ended at the wrong milestone, or a cutover weekend planned three days beforehand.

We run delivery in your governance, on your tooling, with reporting a steering committee can act on: what moved, what is blocked, what it will cost to unblock it. Problems are raised while they are still cheap.

  • PlanningIncrement plans with named owners, dependencies made visible, and a critical path that is maintained.
  • VendorsCoordination across software suppliers and internal teams, including scope and change control.
  • CutoverRunbooks, dress rehearsals, go/no-go criteria and a rollback that has been tested.
  • ReportingWeekly status, risk and issue log, and a steering pack that does not need translating.
  • RecoveryIndependent review and a re-plan for programmes that have already slipped.
You getA live plan, a risk register and decision records — maintained in your tools, not ours.
Typical teamDelivery manager, part-time or full-time; a PMO analyst on larger programmes.
First milestoneA baselined plan and a working risk register within three weeks.

AI

Practice 04

AI solutions

Screened against your data first. Documented well enough to defend.

We start by testing a use case against your actual data, because most candidates fail there and it is cheaper to find out in two weeks than in two quarters. What survives goes into production with monitoring attached.

In a regulated setting a model is only finished when someone can explain how it decides, what data trained it, how it is monitored and who reviews it. We build that record as we go rather than reconstructing it before an audit.

  • ScreeningFeasibility on a sample of your data, with a decision to proceed or stop and the reasoning written down.
  • DocumentsExtraction and classification for contracts, statements, claims and onboarding packs.
  • PredictionForecasting, scoring, segmentation and anomaly detection on your own history.
  • AssistantsRetrieval over internal knowledge, with source citations and access rules that follow the user.
  • OperationsDrift and performance monitoring, retraining triggers, human review points and model documentation.
You getA deployed model or service, its evaluation results, monitoring, and a model card for review.
Typical teamML engineer, data engineer, business analyst; a domain reviewer from your side.
First milestoneA go or no-go on the use case in two to four weeks.

Next step

Not sure which of these it is?

That is normal, and it is usually more than one. Describe the problem in a paragraph and we will come back with what we would do first.