Projects

Questions, answered.

A look beyond the final deliverables, exploring the thinking and decisions that shape the work.

Visuals use illustrative data. Outcomes are real. To protect my employers' and their customers' privacy, every chart, table and code sample uses made-up figures and renamed fields. The results are the actual outcomes.

Principle

Outcome

Skill

Principle · Understand

Financial Process Optimisation

How do you make a critical financial process faster without compromising accuracy?

A daily interest calculation was running too long, and customers were feeling it.

Data Engineering · Data Quality · Business Intelligence

Measured outcome ~13 hrs → <1 minCalculation runtime

See the AnswerHide the Answer

1The challenge & my answer

The challenge

It took about 13 hours. Payments could start before the interest was ready, so customers were paid short and credited late.

What looked like a performance issue was really a financial accuracy and customer experience problem.

My answer

I restructured how the calculation retrieved its data, aggregating once, reusing prepared datasets and simplifying the daily loop, without changing the financial rules. The runtime fell from about 13 hours to under a minute, and a 3am check now confirms the data is ready before payments run.

2The visual story

Press Run Both Versions to watch the old and new process side by side.

Before0h 00m

Waiting to run

After0s

Waiting to run

0h 00mRuntime

0Full scans of the transaction table

Press runAccruals ready in time?

Illustrative timeline. Press run, then switch to After.

Measured~13 hrs → <1 minCalculation runtime

3My reasoning

Traced it back. I followed customer payment discrepancies through the workflow. Execution logs showed the calculation taking around 13 hours.
Found the real bottleneck. The interest rules were sound. The problem was repeated scans of a large transaction table, unnecessary loops and logic that recalculated values multiple times.
Kept the financial logic intact. I chose to preserve the existing calculation rules and change only how data was retrieved, organised and processed.
Validated in two stages. First in a test environment against manual calculations and historical dates, then with a non-writing version run against production data.
Added visibility. There was no completion check, so failures surfaced as customer complaints. A 3:00 am check now confirms the data is there.

4Technical deep dive

Show the Technical Detail

Synthetic example of the pattern, not the production code.

5Outcome & reflection

Measured
Runtime cut from about 13 hours to under one minute.
Observed
The downstream process no longer made incomplete interest payments.
Observed
Less manual investigation of missing accruals and payment discrepancies.
Observed
Earlier warning: delays can be spotted before downstream processing starts.

ReflectionA calculation can be financially accurate but operationally inefficient. Next time, I would add an independent check on the calculated values, designed so it doesn't eat into the performance gains.

Principle · Build

Loan Accrual Migration

How do you prepare existing loan records for migration to a new system while preserving the accuracy and continuity of their financial history?

Moving about 370 loans to a new system meant their interest history had to be right first.

Data Engineering · Data Quality

Supported outcome ~370 loansMigrated, no issues reported

See the AnswerHide the Answer

1The challenge & my answer

The challenge

The new system needed every day of interest history, not just today's balance. But the daily accrual process had defects, and the gaps couldn't be filled from today's balances, because principal changes with every repayment.

My answer

I refactored the daily accrual procedure to remove duplicate entries and fragile calculations, and built a backfill that rebuilt each missing day as the loan stood on that date. After reconciliation and QA, about 370 loans moved to the new system with no issues reported.

2The visual story

Press Fix the Join to see the defect, then Run the Migration.

1 · What was broken

Loan	Accrual date	Schedule row joined	Interest
LN-0042	14 Mar	Instalment 1	₦246.58
LN-0042	14 Mar	Instalment 2	₦246.58
LN-0042	14 Mar	Instalment 3	₦246.58

Interest booked for the day: ₦739.74 (3× too much)

2 · The migration

Old systemdaily defects + missing history

Refactor daily accrualsone row per loan, safe edge cases

Rebuild missing historybalance on each past date

Reconciliationvs schedules and existing records

QA reviewindependent check

New system0loans migrated, no issues reported

Illustrative example. The loan, dates and amounts are made up.

Supported~370 loansMigrated, no issues reported

3My reasoning

Fixed the foundation first. Joining loans directly to repayment schedules multiplied records and created duplicate accruals. Other queries could return unexpected rows or fail on edge cases.
Kept the financial logic intact. The refactoring changed how data was retrieved and protected, not the underlying interest calculations.
Treated history as a sequence of states. Each missing day was rebuilt using the principal actually outstanding on that date, not today's balance.
Made it safe to rerun. Consistent batch references and duplicate safeguards made the backfill traceable and repeatable.
Validated before QA. Reconciled against original repayment schedules and existing accrual records, then passed to a separate QA stage.

4Technical deep dive

Show the Technical Detail

Daily accrual fix

Rebuilding the history, step by step

Synthetic, shortened versions of the real queries, with table and column names changed. The full backfill records fees the same way as interest.

5Outcome & reflection

Supported
About 370 existing loans migrated to the new system, with no issues reported. This is the wider migration result that this work supported.
Delivered
A more reliable daily accrual process, without duplicate entries or fragile edge cases.
Delivered
Missing interest history rebuilt using point-in-time balances, traceable and safe to rerun.
Delivered
Reconciliation against repayment schedules and existing records before formal QA.

ReflectionHistorical financial data is a sequence of changing states, not a snapshot of today. A successful migration needs more than moving records: the calculations, continuity, exception handling and reconciliation all have to be trustworthy.

Principle · Connect

Scaling Business Intelligence

How do you make data more useful as an organisation grows?

Building an analytics function from nothing, while the business kept changing.

Business Intelligence · Data Engineering · Strategy & Insight

Measured outcome 150+ dashboardsAdopted by 8 of 10 teams

See the AnswerHide the Answer

1The challenge & my answer

The challenge

Leaders and teams needed consistent answers they could find for themselves. Instead, every question meant waiting for a manual report.

My answer

I built the analytics function from scratch: agreeing what each metric means, building reusable reporting in Metabase and controlling who sees what. More than 150 dashboards now give 8 of 10 teams answers on demand.

2The visual story

Pick a business question, then switch between Before and After.

The answer

Illustrative figures. The point is the route each question takes to an answer.

Measured150+ dashboardsAdopted by 8 of 10 teams

3My reasoning

Started from the questions. I worked with stakeholders to define metrics and how to read them. For example, an active user is a customer with at least one successful transaction in the period.
Separated recurring from one-off needs. Frequent requests became standard dashboards; complex questions got dedicated analysis.
Consistency without uniformity. Everyone works from the same definitions, even if teams consume them in different formats.
Drove adoption. Stakeholder sessions, documentation, and turning repeated requests into dashboards, steadily reduced manual reporting.

4Technical deep dive

Show the Technical Detail

The real technical work was agreeing definitions before building anything. An illustrative excerpt from a metric dictionary:

Active user

Customer with at least one successful transaction in the period

Used by: Management · Product
Source: Transactions (successful only)

Failed and reversed transactions excluded

New customer

Customer whose account was created in the period

Used by: Management · Growth
Source: Accounts

Registration alone does not count

Transaction success rate

Successful transactions ÷ all attempted transactions

Used by: Operations · Support
Source: Transactions

Pending items reported separately

Dormant customer

No successful transaction in the last 90 days

Used by: Product · Growth
Source: Transactions

Window agreed with Product

Each definition was written once, built into a reusable model, and referenced by every dashboard that used it, so teams saw the same number however they consumed it.

5Outcome & reflection

Measured
150+ Metabase dashboards, adopted by 8 of the organisation's 10 teams.
Observed
Teams retrieve frequently needed information independently, with fewer manual requests.
Observed
Customer Support investigates issues faster with transaction and onboarding status dashboards (not formally quantified).
Observed
Shared definitions, access controls and data quality processes give reporting a consistent foundation.

ReflectionEffective analytics begins with understanding the question behind a request. Next time, I would set up a structured intake process, such as a ticketing system, from day one.

Principle · Connect

Marketing Intelligence

How do you use market knowledge and customer insights to shape a product launch and support marketing decisions?

Launching into a crowded market meant knowing what to say, and to whom.

Strategy & Insight · Business Intelligence

Supported outcome ~6,000 customersIn the first three months

See the AnswerHide the Answer

1The challenge & my answer

The challenge

A sister company offered a ready-made community. But it varied in age, background and what people valued in a financial product, so one message would not work for everyone.

My answer

I worked with Marketing to turn market research and industry experience into a view of what each customer group valued, shaping positioning, communications and taglines. After launch, I built the dashboards that tracked campaigns and acquisition, so the team could keep adjusting.

2The visual story

Pick a customer segment, then watch the launch loop go round, or click any stage.

1 · One community, different needs

What they value
Benefit to lead with
Message angle

2 · Not a one-off: the launch loop

Illustrative segments and messages. The real segments and taglines stay private.

Supported~6,000 customersIn the first three months

3My reasoning

Started with people, not data. A broad audience didn't mean one approach. The question was which benefits mattered to which groups.
Brought market context. Experience in financial services and earlier work with marketing teams helped frame customer motivations and competitive positioning.
Turned insight into decisions. The discussions shaped the launch strategy, including communications and taglines.
Closed the loop. After launch, measurement showed what was working, so the approach could keep improving.

4Behind the scenes

Show the Technical Detail

What went in

Market research, industry experience in financial services, an understanding of the sister company's community, and comparisons with existing alternatives.

What came out

Input into positioning, marketing communications and taglines before launch. After launch, dashboards and reports that let the Marketing team monitor campaign performance and customer acquisition, and use the results to adjust its approach.

5Outcome & reflection

Supported
About 6,000 customers acquired within three months of the official launch. This is the wider launch result that this work supported.
Delivered
Market intelligence and input into marketing strategy, communications and taglines.
Delivered
Campaign and acquisition dashboards that informed later marketing decisions.

ReflectionUnderstanding the business problem is as important as measuring the results. Good analysis doesn't begin and end with dashboards: it also means understanding customers, the competitive environment and the decisions the data is meant to support.

Principle · Question

Customer Risk Assessment

How do you turn an existing risk framework into a practical customer assessment process?

A framework existed on paper. The data to apply it had to be found, questioned and mapped.

Risk & Compliance · Data Quality · Strategy & Insight

Delivered outcome Interim process liveAutomation in development

See the AnswerHide the Answer

1The challenge & my answer

The challenge

Regulation required every existing customer to be risk-rated. Automation was still being built, so the business needed a reliable interim process using the data it already held.

My answer

I mapped the existing framework to the data the business actually held, scored each category in SQL and combined the scores into the existing risk bands. The business got a repeatable interim process and a clear blueprint for automation.

2The visual story

Choose a detail for each category. The framework assigns the score, and the average sets the risk band.

Build a sample customer profile

Customer typeScore –

LocationScore –

Declared monthly incomeScore –

Transaction behaviourScore –

Result

2.00Average of applicable categories

LowMediumHigh

Medium risk

The framework sets each score, not the analyst. Scores and bands here are illustrative. Missing information takes the highest score, so less visibility never means lower risk.

DeliveredInterim process liveAutomation in development

3My reasoning

Mapped the framework to real data. I separated what the business already captured, what was missing, and what needed a reliability check.
Questioned the context. A large customer group was linked to betting activity, so I advised looking at the context behind broad industry classifications, within the framework and regulation.
Handled uncertainty conservatively. Working with Legal on self-reported due diligence answers, and applying the rule that missing information can take the highest category score.
Designed for what came next. The scoring logic and data mappings were written clearly enough for Engineering to automate.

4Technical deep dive

Show the Technical Detail

Customer due diligence answers were stored as JSON, so each category score started by unpacking the questionnaire. A synthetic example for the income category (table and field names changed):

SELECT
  customer_id,
  answer->>'reply' AS income_range,
  CASE
    WHEN answer->>'reply' = '0-10k'    THEN 1
    WHEN answer->>'reply' = '11k-100k' THEN 2
    ELSE 3   -- higher ranges and missing answers score highest
  END AS income_score
FROM questionnaire_responses,
     LATERAL jsonb_array_elements(responses::jsonb) AS answer
WHERE LOWER(answer->>'question') LIKE '%income%';

Similar logic scored each category across several databases. The scores were consolidated, averaged across applicable categories and mapped to the existing bands. Outputs used customer identifiers rather than directly identifying details, and role-based access controlled who could see results. Samples were tested for consistency, and stakeholders signed off the approach.

5Outcome & reflection

Delivered
A repeatable, manually operated process for applying the existing risk methodology.
Observed
A clearer picture of the risk profile of the customer base.
Delivered
Documented requirements, data sources and limitations for the automated version.
Not yet measured
The automation is still in development, so its benefits have not been realised or measured.

ReflectionContext matters before applying any standard framework. Next time, I would bring Engineering into the requirements discussions earlier to smooth the move to automation.

Principle · Build

Monitoring & Workflow Automation

How do you turn routine monitoring into actionable operational workflows?

Getting the right information to the people who need to act, without adding another platform.

Automation · Business Intelligence · Data Quality

Observed outcome Both workflows activeIn use and maintained

See the AnswerHide the Answer

1The challenge & my answer

Problem AData quality issues had no home.

No record of what was found, who owned it, or whether it was fixed.

My answer

A shared Google Sheets tracker that posts new issues, owners and fortnightly reminders straight to Google Chat.

Problem BUrgent alerts lost their urgency.

After the move from Slack, failure alerts went to email, which wasn't fast enough.

My answer

An Apps Script integration that turns Metabase failure alerts into Google Chat cards teams can act on.

2The visual story

Click the buttons on the left to send notifications to the team chat.

A. Data quality tracker

B. Operational alerts

Maintenance mode

Team chat space

A simulation of the notifications, with made-up data.

ObservedBoth workflows activeIn use and maintained

3My reasoning

Kept it simple. Use tools the business already had, and avoid adding another platform that needs training.
Made it actionable. Each notification carries enough context to decide the next step, with a link to the source.
Made ownership visible. Assignment alerts and a fortnightly summary of unresolved issues by owner.
Chose sensitivity on purpose. Better for a team to check a harmless alert than to miss a real service failure.

4Technical deep dive

Show the Technical Detail

A. Data quality tracker → Google Chat

Synthetic outline. An installable edit trigger calls this when an issue is reported or assigned, and a time-based trigger sends the fortnightly unresolved summary.

function sendChatNotification(message) {
  const payload = {
    text: message
  };

  UrlFetchApp.fetch(CHAT_WEBHOOK, {
    method: 'post',
    contentType: 'application/json',
    payload: JSON.stringify(payload)
  });
}

B. Operational alerts: Metabase → Google Chat

Synthetic outline (no real endpoints).

function doPost(e) {
  if (MAINTENANCE_MODE) return ack();          // suppress during maintenance
  const alert = JSON.parse(e.postData.contents);
  const card  = buildCard(alert);              // title, report, chart or table, link
  UrlFetchApp.fetch(CHAT_WEBHOOK, {
    method: 'post', contentType: 'application/json',
    payload: JSON.stringify(card)
  });
  return ack();                                // JSON acknowledgement to Metabase
}

Along the way I fixed edit events not firing automatically (solved with an installable trigger) and duplicate notifications from overlapping triggers. Both were tested in a private Chat space first.

5Outcome & reflection

Observed
A shared record of data issues, owners, statuses and resolutions, replacing informal discussions.
Observed
Clearer accountability through assignment alerts and recurring unresolved-issue summaries.
Observed
Faster awareness of transaction failures through Google Chat.
Not measured
Time saved and resolution speed were not formally measured.

ReflectionOperational tools only work if people can use them within their existing routines. Next time, I would connect alerts to a simple incident log so investigations and resolutions are traceable.

Project notes

Smaller pieces of work

Small-Business Inventory & Pricing Framework

A Google Sheets framework for a small business to manage inventory, set prices based on costs and monitor profitability. The business has remained profitable.

Google Sheets · Pricing · Financial modelling

ShopNow: Quarterly Business Review

A quarterly review for a fictional company, analysing transactions, customer activity, checkout abandonment and financial trends, with recommendations on payment acceptance, checkout usability and customer trust.

View the Presentation

Research publications

From my time in research

Mar 2019Monthly Economic & Financial Market OutlookOpen the PDF ↗ Jan 2019Investment IdeasView the Report ↗ Mar 2020Daily Interbank Market ReportView the Report ↗

Contributed as primary analyst under institutional editorial oversight.

Next step

Fewer reports. Better decisions. Let's start with your question.

Get in Touch Request My CV