Your core system is old because it works. We build the customer screens, the reporting and the reconciliation around it, and we make sure every change leaves evidence behind it.
Most of the risk in a banking or insurance project comes from touching the ledger. We put a documented service layer in front of it, so a new portal, a mobile app or a broker feed integrates through one contract. The point to point connections that built up over the years get retired as each one is replaced. After that the front end moves at its own pace and the core keeps behaving the way the business already relies on.
An audit request is easy to answer when the evidence already exists. We build the delivery pipeline so approvals, test results and access records are written as work moves through it. Who changed what, who signed it off and when it reached production are all recorded at the time, by the system doing the work. When a supervisor asks, you run a query. Nobody spends a week rebuilding the story out of a mailbox.
The batch schedule decides when everything else is allowed to run, and a feed that arrives late in the small hours turns into a morning of surprises. We map what depends on what, then build the checks that compare balances, statements and incoming files automatically. Breaks are raised the same day with enough detail to act on. The knowledge currently held in one analyst's head ends up in the system, which matters most on the week that analyst is on leave.
A feature that takes two weeks to build takes six to release here, and most of that difference is not waste. Somebody other than the author has to approve the change. The test evidence has to exist before the approval rather than be written up after it. The ability to deploy to production is kept apart from the ability to write the code. The release lands in a window operations agreed to rather than on the afternoon it passed testing. We plan against that from the outset instead of meeting it in the last fortnight, which means the approval steps are inside the estimate and the evidence is produced by the pipeline as work moves rather than assembled by a person the night before. The cost is honest lead times.
Outsourcing does not move accountability, so the questions asked of a supplier are really questions about you. Expect to need answers on where the data sits and whether it ever leaves the country, who at our end can reach your systems and how that access is removed the day somebody leaves, whether you can audit us and on what notice, who our own subcontractors are, and what happens to your systems and data if the arrangement ends. We would rather answer all of that in the first month than at a supervisory review. It also shapes the build: named accounts rather than shared ones, an exit plan written while everyone is still friendly, and the code and cloud accounts in your name from the first commit rather than transferred at the end.
Account views, applications, claims and self-service that release on their own schedule because they sit outside the core rather than inside it. The ledger keeps its calendar and the customer stops noticing that it has one.
The screens the people who sell and service your products use all day. Usually the oldest software in the building, and the first place a process quietly forks into somebody's private spreadsheet.
One documented contract instead of another point to point connection, with an old one retired for each new one added, so a core upgrade becomes a change in a single place.
Scheduled comparison of balances, statements and incoming files, with breaks raised the same day and enough detail attached that whoever picks one up does not begin by asking what it means.
Statements, policy documents, letters and regulatory notices generated from the record, versioned, and reproducible years later exactly as the customer received them rather than as the template renders today.
Regulatory returns and management reporting built from the same numbers, so the figure the board sees and the figure that gets filed never have to be reconciled by hand the night before.
It stays. The work is building around it so it keeps doing the one thing it is genuinely good at, which is being the record everybody in the business already trusts.
Instant transfer schemes, batch clearing and card networks. Their cut-offs decide when your systems are allowed to be busy, and those windows are rarely convenient for anything else you want to run.
Postings, sub-ledgers and the month end. Nothing new is allowed to make the close harder, which is the constraint finance raises last and means most.
Screening services, watchlist feeds and case management. The tuning matters more than the integration, because an alert queue nobody can work through is the same as no screening at all.
Roles, approvals and joiner, mover and leaver processes. Most access findings in this sector are not intrusions, they are people who changed job and kept everything they had before.
Where reporting should read from, so an analyst's query never lands on the system clearing payments at four in the morning and nobody has to explain why the batch ran late.
Nobody has the full list and everybody has a partial one. Producing it is about a fortnight of work, and it usually changes what the programme does first.
Pick a customer journey that changes often, move it outside the core behind the service layer, and let it release on its own calendar as proof that the boundary holds.
There is always one, it lives in a spreadsheet, and one person knows where the exceptions hide. Automating it matters most during the week that person is on leave.
Ask for the evidence behind a change made three months ago. However long that takes today is the number worth fixing, and it is usually the number that starts the conversation.
No, and you should be wary of anyone who opens with that. The core stays; the work is building around it so customers and staff get modern screens and the record of truth stays where it is. That means an integration layer that can absorb a core upgrade without the customer-facing product noticing.
It is designed in from the start, because it cannot be added convincingly afterwards. Every action that touches a policy, a claim or a balance is recorded with who did it, when and what changed, and corrections are posted as new entries rather than edits. When a regulator asks why a decision was made, the answer should already be in the record.
By putting the fast-moving work outside it. Customer-facing screens, document generation and reporting can change on their own schedule if the boundary is drawn properly, while the core keeps its release calendar. Most of the frustration in this sector comes from work being trapped inside a system that cannot move at the pace the business needs.
Yes, and it is better to start there than to meet it at the end. Penetration testing, code review requirements, data residency and supplier questionnaires all shape the design, and knowing them at the outset costs a conversation. Discovering them at go-live costs a rebuild.
It gets planned for rather than argued with. Freezes cover the periods where the business cannot absorb a surprise, which for most institutions means year end, the statement run and any filing window, and they are the reason a delivery date here is set backwards from the calendar rather than forwards from an estimate. In practice, anything meant to be live before a freeze is finished and released with weeks to spare rather than days, work that would land during it is either configuration or held, and the fixes permitted mid-freeze are agreed in advance with a named approval route. A supplier who only discovers the freeze in November has already lost you a quarter, so we ask for the calendar in week one.
Not without masking, and preferably not at all. Production copies are how customer records end up in environments with looser access and weaker monitoring, and they are one of the more common findings in this sector. Where realistic data is genuinely needed, for a volume test or a migration rehearsal, it is masked on the way out by a documented process, refreshed on a schedule, and held with the same access controls as production rather than the defaults a development team is used to. That has a cost worth stating: masked data breaks some referential rules and hides some real defects, so the awkward cases have to be built deliberately. It is still far cheaper than explaining a customer table sitting on a test server.
Named accounts, never shared ones, scoped to the work and removed when the work ends rather than when somebody remembers. Where you run privileged access management we use it, and where you do not, we would rather you did, because the alternative is a supplier account with standing rights that nobody reviews from one year to the next. We expect to be included in your access reviews and treated like any other group of users: the same joiner, mover and leaver process, the same evidence, the same removal on the day a person comes off the work. If it helps your review, we will write our own side of it down. It is a short document and it saves an uncomfortable meeting later.
Often yes, and it is usually the right first move. With the boundary drawn properly, quotation, pricing, document generation, servicing screens and reporting can all move at the speed the business wants while the ledger keeps its own release calendar. What cannot move outside is the record of value itself, and attempts to hold a second balance somewhere friendlier are how institutions end up with two numbers and a reconciliation nobody asked for. The rule we work to is that one place holds the money and everything else asks it. Where a product genuinely needs a change inside the core, we scope and price that as core work rather than smuggling it into a portal project and discovering it in testing.
We are happy to answer any questions you have and help you work out which of our services fit your needs.
