Will you work inside our change approval process or bring your own?

Yours. If a change needs a ticket, a named approver or a freeze window, our changes take the same route as your team's. Where no process exists yet, we write one down for your review before we use it.

Can you do this work without access to live account or card data?

Yes, and we prefer it. Most of the work runs on masked or synthetic records and on logs. Where production access is needed, it is named, time-limited and granted by your team through your own access tooling.

Do you work on card data directly?

We avoid it. Where cardholder data is in scope, we design so that it stays with your PCI DSS certified payment provider and your own systems hold tokens only. If a change would bring card data into your systems, we flag it before any work starts.

Sector IND 01

Payments and fintech

Payments and fintech work, as Blueharbour does it, is engineering on systems that move or record money: payment initiation, ledgers, reconciliation and the reports a bank partner or supervisor reads. Every change we make leaves a record of what ran, who approved it and which transactions it touched, so that any payment can be traced from request to settlement after the fact.

Who this is for

Heads of engineering, CTOs and heads of risk at payment institutions, e-money issuers, lenders and the software companies that serve them, usually with an engineering team of their own and a partner bank asking questions. It fits when the systems already run and the gap is evidence, integration or operations. It does not fit a company that needs a licence application written or a core banking platform selected.

Problems you will recognise

01
Your partner bank asks for proof that production changes are reviewed, and the honest answer lives in chat threads and in two people's memory.
02
Reconciliation breaks at every month end on the same edge cases, and one engineer fixes them by hand with a script nobody else has run.
03
A payment provider retires an API version, and the integration has no test that would show what changes for your flows.
04
An incident report has to name which transactions were affected, and getting that answer from the logs takes a day of queries.

European regulation · a condition, not a sector

The regulatory condition

Financial entities in the EU work inside two texts we meet most often. The revised Payment Services Directive, directive (EU) 2015/2366 (PSD2), sets rules for payment services and the firms that provide them. The Digital Operational Resilience Act, regulation (EU) 2022/2554 (DORA), sets requirements for ICT risk management, incident reporting and the oversight of third-party ICT providers. This is general information, not legal advice. Whether and how it applies to your company is a question for your own counsel. Our part is the engineering evidence that conversation needs.

What we do here

Managed services

Release records and monitoring are where change evidence comes from, so they come first.

AI engineering and automation

Reconciliation exceptions are rule-heavy, and an automation without a written governance record becomes a finding of its own.

Web and product engineering

Provider and bank integrations carry the money; the internal interface is where staff see a payment and correct it.

Cloud, data and modernisation

A ledger you can query by transaction is what makes tracing possible, and old batch jobs are where traceability usually stops.

Security and compliance readiness

These three produce the control register, the data map and the delivery record a resilience review reads.

Where evidence is captured on one payment

One payment from request to report. Each marked stop is a record that has to exist afterwards, written by the system, not reconstructed by a person.

Read as a list

01
Request. The payment request is logged with one id that every later record carries.Marked: request id
02
Authorise. The approval or risk decision is stored with the rule or person that made it.Marked: decision record
03
Provider call. The provider's response is kept as received, not only the status we derived from it.Marked: raw response
04
Settle. The settlement file is stored unchanged with a checksum.Marked: file checksum
05
Reconcile. Every mismatch gets a case with an owner and a resolution note.Marked: case log
06
Report. The report names the query that produced it, so a reviewer can run it again.

A first engagement

01
Trace one payment type
Exists afterA written path of one payment type from request to report, naming every system and log it passes through.
02
Mark the gaps
Exists afterA list of the points where the path leaves no record, ordered by what a reviewer would ask about first.
03
Close the first gap
Exists afterOne change in your repository, reviewed and released, that writes the missing record.
04
Hand over the trace
Exists afterThe path, the gap list and the change notes in your own documentation, owned by your team.

Questions about this sector

Will you work inside our change approval process or bring your own?: Yours. If a change needs a ticket, a named approver or a freeze window, our changes take the same route as your team's. Where no process exists yet, we write one down for your review before we use it.
Can you do this work without access to live account or card data?: Yes, and we prefer it. Most of the work runs on masked or synthetic records and on logs. Where production access is needed, it is named, time-limited and granted by your team through your own access tooling.
Do you work on card data directly?: We avoid it. Where cardholder data is in scope, we design so that it stays with your PCI DSS certified payment provider and your own systems hold tokens only. If a change would bring card data into your systems, we flag it before any work starts.

Name the problem you see this week

Write a few lines about one problem from your own systems. We reply with the questions we would ask first.

Start with one problem

An email exchange first, no call needed.