Skip to content
Dino Correia
Let's talk

Case studies · Fintech · Data · Integrations · Platforms · AI

Problems like yours, and how they were solved

Systems where data, business rules and external services had to come together, and where the hard part was never writing the code. Each one is told as the decision it actually was: what was happening, what everyone assumed, what had to be understood, and what changed. This is the kind of thinking I bring to a project.

Let's talk See services →
working in software and technology
10+ years
primarily in fintech
5 years
across 3 companies
20+ projects
users supported by systems worked on
10,000+
transactions processed annually
500K+
external integrations
20+
records involved in data migrations
6.5M+
platform migrations from third parties to internally owned systems
2

Business problem: What's actually going wrong, for whom, and what solved looks like.

Case studies

Five problems, and how each one was actually decided

Each one is generic by design (no client names or confidential details), and each comes with something to try.

FINTECH · CREDIT · DATA

Lending Decisions That Survive Unreliable Data

Credit decisioning systems where several sources of financial and customer data had to be brought together, in real time, to support a lending decision.

The problem

Every decision depended on external providers that each had their own data format, their own latency, and their own way of being unavailable at exactly the wrong moment. The lending rules also changed: what counted as a relevant signal one quarter did not always hold the next.

What everyone assumed

The work was framed as improving the scoring model. The model was the visible part, so it looked like the bottleneck.

What needed to be understood

  • Which of these data points actually change the decision, and which are just being collected?
  • What should happen to an application when one provider is slow, or down, or returns something unexpected?
  • How often do the rules change, who changes them, and how long does a change currently take to ship?
Interactive Click a data source to take it offline
Credit Decisioning 4 of 4 sources
Credit Result

Every source responded, so the decision runs end to end.

A decisioning system is only as reliable as its least reliable source. Designing for partial failure is part of the architecture.

The options

Improve the model in place
Fastest to start, but every rule change would keep dragging the provider integrations along with it.
Integrate each provider directly into the decision flow
Simple per provider, until one of them fails and takes the decision down with it.
Put a decisioning boundary between the rules and the sources
More design work up front, but the two things that change most stop colliding.

The decision

Separate the decisioning logic from the data sources, so each provider sits behind a boundary that normalises its data and defines what happens when it fails.

What changed

Scorecard rules could be changed without reopening provider integrations, and a single provider having a bad day stopped being an outage for the whole decision.

Facing something like this? Architecture Review is usually where it starts.

Further reading: Credit Decisioning: Build or Buy a Decision Engine?, Credit Decisioning: Designing for Data You Do Not Control.

DATA · ARCHITECTURE · MIGRATION

Moving Off a Third-Party Platform Without Inheriting It

Migration of data and business processes from a third-party platform into an internally owned system, including a complete rebuild of the underlying database.

The problem

The data model had been shaped by someone else's product constraints, not by the business using it. Fields meant different things to different teams, and some of the rules everyone relied on existed only inside the old platform's behaviour.

What everyone assumed

It was described as a data migration: export the records, import the records, switch over.

What needed to be understood

  • What does each field actually mean, and does the business agree on that meaning?
  • Which of these constraints are real business rules, and which are just the old platform?
  • What breaks if a record arrives incomplete, and who decides what to do about it?
Interactive Play the migration, or click a stage

Export from the third-party system

full_name
Jane Smith
status
ACT
created
03/04/2019

The export follows the old platform's model, not the one your business needs.

Copying records is the easy part. The real work is the model, the mapping rules, and the assumptions nobody wrote down.

The options

Lift and shift the existing model
Lowest migration risk, highest long-term cost - the old limitations come along for the ride.
Redesign the model and migrate into it
More transformation work and more assumptions to confirm, but the new system is modelled on what the business needs now.
Run both in parallel indefinitely
Avoids a cutover, but doubles the surface area that has to stay correct.

The decision

Redesign the data model first, then treat the migration as a transformation problem with explicit rules, a validation step, and a review queue for records that fail it.

What changed

6.5M+ records migrated into a model the business owned. Ambiguities - date formats, split name fields, status codes - were surfaced and confirmed before the move rather than discovered in production.

Moving away from a third-party system creates an opportunity to rethink the underlying model, rather than simply reproduce the limitations of the old one.

Facing something like this? Migration & Integration Assessment is usually where it starts.

Further reading: Accounting Data Migration: Moving Financial Data Safely, Big Bang vs Phased Migration: How to Choose, Data Migration Testing: How to Prove the Data Is Right, Data Migration Checklist: What to Plan Before You Move, Leaving a Third-Party System? Plan the Data Migration First.

INTEGRATIONS · API · ARCHITECTURE

A Reliable Boundary Between Systems That Disagree

APIs connecting internal systems with external providers, partners, and clients - KYC, open banking, accounting platforms, e-signature, and credit reference agencies.

The problem

Several internal processes depended on external providers, and each one had a different API, a different data model, and a different way of failing. A change at any provider could reach deep into the business logic that used it.

What everyone assumed

Each one was treated as a separate task: connect to this provider, then connect to the next.

What needed to be understood

  • What information genuinely has to cross this boundary, and what are we sending out of habit?
  • What does the user see while a provider is unavailable?
  • How will we find out an integration has stopped working - before a customer tells us?
Interactive Pick a concern to see where it shows up
Your system
{ id, amount, status }
External provider

What information enters and leaves each system?

Agree the fields, formats, and IDs on both sides, and write them down.

An external API isn't just a connection. It brings dependencies, failure modes, contracts, and change.

The options

Call each provider directly where it is needed
Quickest for the first integration; every provider change then touches many places at once.
One generic adapter for all providers
Tidy in theory, but providers differ in ways that a single abstraction ends up hiding badly.
A thin owned layer per provider, with shared rules for failure and change
Slightly more code, but a provider version bump lands in one place and failure behaviour is decided once.

The decision

Treat each integration as a designed boundary rather than a connection: an owned layer per provider, with agreed data contracts, explicit timeout and retry behaviour, and failures made visible.

What changed

20+ external integrations built on the same set of decisions, so a new provider was a known shape of work rather than a new investigation each time.

Facing something like this? Migration & Integration Assessment is usually where it starts.

Further reading: Codat vs Direct Accounting APIs: How to Choose, Xero API Integration: What to Plan Before You Build, System Integration: Decide the Shape Before You Connect, API Integration Checklist: What to Decide Before You Connect.

PLATFORMS · API · B2B

One Platform, Many Brands, No Bespoke Forks

White-label systems letting external clients offer services under their own brand while running on shared internal infrastructure.

The problem

Each client wanted something slightly different, and each difference was individually reasonable. Accepted one at a time, they would have turned a shared platform into several bespoke systems wearing the same name.

What everyone assumed

Client requests were read as feature requests, to be built for whoever asked first.

What needed to be understood

  • Is this a configuration difference, or a genuinely different product?
  • How is one client's data kept separate from another's, and who can prove it?
  • What has to stay identical across every client for this to remain one platform?
Interactive Pick a client to follow its path through the platform

Shared platform

Shared APIs & services
Client A data Accessible
Client B data Isolated
Client C data Isolated

Experience

Own brand & domain

Features for Client A

  • Onboarding
  • Payments
  • Reporting
  • API access

One shared layer, many clients: reusable services, each client's data kept apart, and configuration instead of bespoke systems.

The options

Fork per client
Every client gets exactly what they want, and every fix has to be applied n times.
One rigid platform, no variation
Cheap to maintain, but loses the clients whose differences are real.
A shared core with an explicit configuration surface
Requires deciding up front what is configurable - and holding that line when a client asks for more.

The decision

Define what varies per client as configuration, keep everything else shared, and enforce data separation in the platform rather than in each client integration.

What changed

Onboarding a new client became a configuration exercise rather than a build, and a fix to the shared core reached every client at once.

Facing something like this? Solution Design Sprint is usually where it starts.

AI · AUTOMATION · SYSTEMS

Deciding Where AI Earns Its Place

More recent work with AI agents and automation, particularly where they reduce manual processing or let systems handle information that previously needed a person.

The problem

The request usually arrives as "can we use AI for this?" - which is a solution looking for its problem. Some of the candidate tasks genuinely needed it. Others were a scheduled job with extra cost and less predictability.

What everyone assumed

That the interesting question was which model to use. It is almost never the interesting question.

What needed to be understood

  • How much does the input actually vary? Fixed rules handle fixed shapes perfectly well.
  • What is the cost of a wrong answer here, and who catches it?
  • Does this need judgement, or just consistency?
Interactive AI or plain rules? Make your call for each task

  1. Extract totals from supplier invoices that arrive in many different layouts.

  2. Reject an application when a required document is missing.

  3. Summarise a long customer case history for the person reviewing it.

  4. Send a reminder three days before a payment is due.

Not every automation problem needs AI. Not every AI problem should be automated.

The options

Deterministic automation
Cheaper, auditable, gives the same answer every time - and cannot handle variety.
AI in the workflow
Handles messy, varied input, at the cost of predictability and a confidence check.
AI with a human decision point
Keeps the judgement where the risk is, but only pays off if the human step is genuinely faster than doing it manually.

The decision

Sort the work by how much the input varies and what a wrong answer costs. Rules where the shape is fixed, AI where it is not, and a person on the decision whenever the cost of being wrong is high.

What changed

Manual processing dropped where it made sense to, and the parts that stayed deterministic stayed cheap and auditable.

Facing something like this? Technical Decision Workshop is usually where it starts.

The common thread

Different systems, the same underlying problem

Multiple systems, multiple sources of information, competing requirements, and uncertainty about the best way forward.

That's where I do my best work: understanding the moving parts, making the problem visible, exploring the options, and designing something that is practical to build and operate.

  1. 01

    Start with the problem

    The technology is rarely the first question that needs answering.

  2. 02

    Data changes architecture

    Where data comes from, who owns it, how reliable it is, and how it changes often determines how the system should work.

  3. 03

    Integrations are part of the architecture

    An external API isn't simply a connection. It introduces dependencies, failure modes, contracts, and change.

  4. 04

    Simple beats sophisticated

    Complexity should solve a real problem, not create one.

  5. 05

    Constraints matter

    The technically elegant solution isn't always the right one once cost, time, people, regulation, and existing systems are considered.

  6. 06

    AI changes the design space

    AI makes some previously expensive workflows possible, but reliability, context, and boundaries still matter.

Path

How this took shape

  1. Software Engineering
  2. Fintech
  3. Technical Leadership
  4. Architecture, Data & Integrations
  5. AI & Automation
  6. Agaya Cloud Now

Across: Cloud · APIs · Databases · Data · Integrations · Automation · AI · Distributed Systems · Fintech

Now: founder of Agaya Cloud, building TrueSignal, which pulls together the systems a company already has and flags problems before they escalate. Also the builder of Asklet.

Explore Agaya Cloud →

Facing something similar?

A messy architecture, a difficult integration, unclear requirements, or a technical decision you're not sure about. We can start with the problem, not the technology.

Let's talk Email me