FinTech Fundamentals Case Studies
Finance5 Case StudiesUpdated Sep 2026
The five cases below come from payments, small business lending, brokerage security, payroll software, and consumer credit. Each opens with a situation a practitioner would recognize: a release that stalls settlement, two reports that disagree, a suspected account compromise, a design choice under cost pressure, and an automated tool that promises speed. The analysis in each case covers business objectives, available evidence, operational constraints, and stakeholder impact. Read them with a pen. The reasoning matters more than the tidy endings, and several decisions were close calls.
Case Study 1
Settlement Queue Failure After a Late Thursday Release
Tallgrass Remit, a payments processor that moves about 2,400,000 card and transfer messages each day for regional banks
The situation
Tallgrass Remit shipped a change to its settlement scheduler late on a Thursday afternoon. The change reworked how batched transfers were grouped before submission to the clearing partner. Within the first hour, queue depth climbed from a normal range of a few hundred items to more than 18,000, and batch completion fell below 60 percent. Customer balances updated normally, so early alerts read as a reporting lag rather than a payment failure. By the time the on-call engineer, Marisol, paged the payments lead, about 3,100 transfers had not reached the partner and were at risk of missing its same-day cutoff.
The challenge
Marisol had to decide whether to roll back the release, which would undo two weeks of work on an unrelated fee change bundled into the same deployment, or to patch the grouping logic live. The rollback would clear the queue but might strand transfers already half submitted to the partner. Finance operations wanted a firm answer on which transfers would settle before the partner's evening cutoff. Nobody on the call could say yet whether the duplicate submissions seen in one log sample were real or a logging artifact.
Analysis
The objective was narrow and time bound: get every transfer that could settle by the partner cutoff into the clearing file, and avoid any double payment. That ordering shaped the evidence work. The team pulled submission logs, partner acknowledgments, and ledger entries, then matched them by batch identifier rather than timestamp, since the two systems' clocks were about four seconds apart. Teams grounded in FinTech Fundamentals usually start by asking which evidence is authoritative for money movement, and here the partner acknowledgment file won over the internal log. Operational limits were tight: the rollback was a full deployment with a manual database step, and only two people had access to the partner gateway.
Stakeholder impact ran in several directions at once. Roughly 3,100 late transfers meant small business customers would see delayed payroll, and the partner bank would face its own regulatory reporting questions. Customer support had no script for a balance that looked correct but showed a pending transfer that had not moved. The team chose a partial path: pause new batch creation so the queue stopped growing, patch the grouping function behind a flag, and resubmit only the batches whose partner acknowledgments were missing. The rollback stayed on the table as a fallback, held in reserve until the resubmission results came back and reconciled.
- Detect and scope Confirm the queue, the affected partners, and the cutoff time before choosing any fix.
- Stabilize flow Freeze new batches and protect in-flight transfers from further duplication.
- Verify and resubmit Reconcile against partner acknowledgments before any retry reaches the rail.
- Prevent recurrence Add replay tests and deployment checks that would have caught the grouping defect.
Actions taken
- Froze new batch creation within the first half hour and posted a status note to partner bank operations with the cutoff time and affected transfer count.
- Matched partner acknowledgment files against ledger entries by batch identifier, which separated 2,688 transfers safe to resubmit from 412 the partner had already accepted, so nothing would be paid twice.
- Patched the batch grouping function behind a feature flag, tested it against replayed submissions from the previous six hours, and enabled it for one partner before opening it to the rest.
- Set a post-incident rule that any release touching settlement paths ships with a replay test and a written rollback plan, and that the partner acknowledgment file becomes a required check in the deployment pipeline.
Results
The queue drained in about two hours after the flagged patch reached all partners. Of the 3,100 transfers at risk, 2,688 settled before the partner cutoff, and the remaining 412 were already complete on the partner side, so no customer received a duplicate payment. Two small business customers still reported late payroll, and the team issued manual credits within a day. The post-incident review produced the replay test and the pipeline check, and the next settlement release went out with both in place. The rollback was never needed, which the team recorded as a lucky outcome rather than a sound plan.
Questions for discussion
- Which evidence should have been treated as authoritative for money movement, and why did the internal log lose that role during the first hour?
- When a release bundles an unrelated change with a critical fix, how should the team weigh the cost of rollback against the cost of a live patch?
- What would a customer-facing script look like for a balance that is correct in one system and pending in another?
Case Study 2
Conflicting Delinquency Rates Across Two Monthly Reports
Corvane Lending, a small business lender with about 60,000 active borrower accounts and funding relationships with three outside partners
The situation
Corvane Lending reports delinquency rates to its funding partners and to its own credit committee each month. In the most recent cycle, the two reports disagreed by 1.8 percentage points on the same portfolio, enough to change which regional segment triggered a tightening review. The credit committee's figure came from the risk warehouse, while the partner report was built from a separate extract that pulled loan status from the servicing platform. Analysts had built both reports over several quarters, and each had passed its own review. Nobody had compared them line by line until a portfolio manager, Desmond, asked why the numbers differed on a single segment.
The challenge
The reconciliation had to be finished before the next funding draw, which depended on the partner report. Desmond needed to know which figure was right, not just which was closer to expectation. The two systems used different cutoff dates for when a loan counted as thirty days past due, and servicing records for about 1,200 loans had changed status during the gap. Revenue reporting and credit decisions both drew on this data, and no single owner had authority over both pipelines.
Analysis
The objective was one defensible delinquency figure that both the credit committee and the funding partners would accept, reached without rebuilding either pipeline. That shaped the work toward lineage tracing. The team traced each report to its source tables and logged every join, filter, and date rule. The evidence was uneven. The warehouse kept load timestamps but no status history, while the servicing platform kept history but overwrote the as-of date on corrections. Reconciliation teams tend to treat a metric as only as stable as its least documented filter, and here the thirty-day rule used the first missed payment date on one side and the latest statement date on the other.
Stakeholder impact fell unevenly across lending and risk. Funding partners used the partner report to release capital, so a restated figure could delay draws on several facilities. Extract maintainers could not change warehouse logic, and the risk team did not own servicing data. The team settled on three moves: an explicit as-of date, one thirty-day rule across both pipelines, and a monthly tie-out before any report leaves the building. Leadership accepted a visible short-term cost, since the first tie-out flagged about 1,200 records for manual review.
Actions taken
- Traced both reports to source tables and documented every join, filter, and date rule in a shared lineage sheet that both teams could edit.
- Rebuilt the thirty-day delinquency rule as a single shared definition, then ran both pipelines against the same 90 sample loans and compared each result by hand.
- Added a reconciliation check that compares loan counts and outstanding balances by status between the warehouse and the servicing extract, and blocks release when the gap exceeds an agreed tolerance.
- Assigned a named owner for each source extract and for the shared definition, with a change log that records any edit to a status or date rule before it reaches a report.
Results
The tie-out found the gap came almost entirely from the as-of date. The warehouse measured thirty days from the first missed payment, while servicing measured from the latest statement, and the difference moved about 900 loans across the threshold. After the shared definition went live, the two reports matched within a tolerance of 0.1 percentage points. The partner report was restated before the next draw, and the funding partner accepted the explanation without delaying the facilities. Monitoring has since caught two small mismatches in the early days of new cycles, both traced to late servicing updates rather than logic errors.
Questions for discussion
- Which source should own the definition of a delinquent loan when two teams depend on it, and how would you record that decision?
- What evidence would convince you that a reconciliation tolerance is set too loosely to catch a real problem?
- How should a lender handle a restated figure that has already influenced a credit decision?
Case Study 3
Unusual Transfer Requests From an Advisor Login
Brindle Ridge Capital, a mid-size wealth manager and brokerage with about 85,000 client accounts
The situation
Brindle Ridge Capital's fraud monitoring flagged a cluster of withdrawal requests on forty-one client accounts over two days, all initiated from sessions tied to one advisor's login. The requests were small enough to avoid the standard review threshold but routed to a newly added external bank destination. The advisor, Teodora, had been active in the portal for several weeks, and her last password change predated a phishing awareness campaign by only a few days. The security operations team had access to authentication logs, portal session records, and the outbound payment queue, but the portal vendor's audit trail had a retention window of about thirty days.
The challenge
The team had to decide how far to widen the investigation before anything was frozen. Locking Teodora's account would stop new requests but could also tip off an attacker still operating inside her session, and it would interrupt advisors serving clients who had scheduled reviews that week. Forty-one accounts were already affected, and the security lead, Anand, needed a scope estimate before the compliance team could decide on client notification. Evidence in the vendor's logs would age out in under a month.
Analysis
The objective had two parts that pulled against each other: stop further transfers quickly, and keep the evidence intact enough to explain events to clients and regulators. The team sequenced the work accordingly. They exported session records and authentication logs to write-once storage and recorded chain of custody for each file. Scoping came next, pivoting on destination accounts, device fingerprints, and source address ranges across every session, not only the advisor's. Investigators who handle these cases usually anchor scope to indicators an attacker cannot easily rewrite, which here meant the processor's destination records rather than the internal label attached to each request.
Stakeholder impact reached well beyond the security team. Forty-one clients had money in transit and would expect a clear account of events. Advisors had reviews scheduled and needed to know whether their logins could still be trusted. Compliance needed proof that the firm acted inside its notification window. The team froze transfers to the new destination only, forced re-authentication across the advisor's team, and placed her account in read-only mode rather than disabling it. That kept the investigation open and let advisors keep serving clients while scope was confirmed.
Actions taken
- Exported authentication logs, portal sessions, and the outbound payment queue to write-once storage within the first two hours, with hashes recorded for each file.
- Requested the vendor's retained audit trail in writing on the first day, citing the thirty-day window, and asked for an extended hold while the scope review ran.
- Pivoted on destination accounts, device fingerprints, and source addresses to identify 41 affected clients and 6 further sessions that the first alert had missed.
- Documented each containment step with a time, an approver, and a reason, so compliance could reconstruct the response without relying on memory.
Results
Scoping confirmed that the forty-one accounts were the full set of affected clients, and six further sessions had touched the portal without moving money. Outbound transfers were blocked before settlement, and no client funds were lost. The preserved logs supported a notification decision that compliance could defend, and the vendor extended its hold just before the retention window closed. Teodora's credentials were reset and her device was reimaged, and her access returned after a supervised week. The review also added a rule that sends new external destinations to second approval regardless of amount.
Questions for discussion
- What would have changed in the scope estimate if the team had locked the advisor account in the first hour instead of preserving evidence first?
- How should a firm weigh a client's need for timely access against the risk of leaving a possibly compromised session in place?
- Which indicators would you trust most when a vendor's own records are slow or incomplete, and why?
Case Study 4
Choosing a Cache Layer for Peak Payroll Approval Traffic
Pelham Ledger Systems, a payroll and expense platform serving about 900 mid-size employers
The situation
Pelham Ledger Systems runs a platform where employers approve payroll runs, expense reports, and contractor payments. Approval traffic is light for most of the month and then spikes sharply in the last two business days before pay dates, when managers review batches in parallel. During the most recent peak, average approval latency rose from under 300 milliseconds to more than 2 seconds on the largest tenants, and the database cluster ran near its connection limit. The platform team had been asked to fix latency without a large increase in monthly infrastructure spend, which had already grown in each of the last four quarters.
The challenge
Three options were on the table. Read replicas and query tuning were low risk but would not relieve connection pressure at peak. A shared cache for approval state would cut reads sharply, yet approvals must never be applied twice, so consistency mattered. A separate approval service with its own store was the cleanest design and the most expensive to build and run. Each option had a different owner and timeline.
Analysis
The objective was to bring peak approval latency under one second for the largest tenants without exceeding an agreed infrastructure ceiling. Request traces from the last peak showed that most slow calls spent their time waiting for a connection, not running queries, which weakened the case for tuning alone. The team also replayed a sample of that traffic in staging, though staging did not reproduce the tenant mix. Capacity planners often treat a replay like this as a screen rather than a verdict, ranking each option by how much uncertainty it carries.
Stakeholder impact differed by role. Large employers felt the spikes first and were most likely to leave after a slow pay-date week. Payroll operations needed proof that no run would be approved twice, which turned any cache holding approval state into a control question. Platform engineers would carry the on-call load of whichever design won. The team chose a staged path: pool connections and add replicas now, cache only read-heavy approval views, and defer a separate service until those changes were measured against a realistic peak.
- 1Client requestApproval call arrives at the API gateway with a tenant identifier.
- 2Connection poolerRequests queue briefly for a warm connection instead of opening new ones at peak.
- 3Read pathDashboard reads hit the cache first, falling back to the replica on a miss.
- 4Write pathApprovals always go to the primary, where the batch version check blocks duplicates.
- 5Audit recordEvery decision is logged with the approver, timestamp, and batch version.
Actions taken
- Added a connection pooler in front of the primary database and raised the pool limit only after confirming the server's memory headroom at peak.
- Moved approval history and reporting reads to a read replica, with a lag alert set at two seconds so managers never see a stale approval state.
- Introduced a write-through cache for the read-heavy approval dashboard only, keyed by batch version, and kept the write path on the primary so duplicate approvals stay impossible.
- Ran a seven-day load test against a copy of the largest tenant's traffic profile, with a go or no-go threshold set before the test began.
Results
The pooler and replica brought median approval latency under 400 milliseconds in the next peak, and the 95th percentile dropped from over 2 seconds to about 900 milliseconds. The dashboard cache handled most read traffic, but the load test showed that a separate service would still be needed if tenant count doubled. Infrastructure spend rose by a modest amount that stayed inside the ceiling. The team deferred the separate approval service and recorded explicit triggers for revisiting it, including sustained connection saturation across two consecutive peaks.
Questions for discussion
- Which measurements would have made the case for a separate service stronger or weaker before anyone committed budget?
- When a cache holds state that controls money movement, what evidence should be required before it is allowed to serve writes?
- How should a platform team explain a deferred architecture decision to an executive who expected the larger investment?
Case Study 5
Automated Income Verification for Personal Loan Applications
Hollis Park Mutual, a credit union with about 310,000 members and a small consumer lending unit
The situation
Hollis Park Mutual's consumer lending unit processes personal loan applications that require proof of income. Underwriters currently read pay stubs and bank statements by hand, which takes about two business days per file and creates a backlog in busy months. A vendor offered a document extraction and scoring tool that promised to cut review time by more than half and to auto-approve a large share of clean files. The pilot ran on a sample of 2,000 recent applications, and the vendor's summary showed time savings and strong agreement with past decisions. The unit's risk committee asked for more than that summary before any rollout.
The challenge
The vendor's headline accuracy figure hid how the errors were distributed. Extraction failures clustered on self-employed applicants, on pay stubs from smaller payroll providers, and on scanned documents with handwritten notes. Those are the applicants most likely to be turned down by a model trained mostly on salaried files. The team needed to know whether the tool would speed up decisions evenly or shift delays and denials onto a particular group, and whether underwriters could catch errors in time to matter.
Analysis
The objective was faster decisions without weaker credit judgment or uneven outcomes, so the evaluation had to measure more than average accuracy. Before reading pilot results, the team fixed three metrics: extraction error rate by document type, false approval rate on files later found inconsistent, and time to decision by applicant segment. The evidence was thinner than anyone wanted. Only about 140 pilot files had later servicing outcomes, and the self-employed group within them was small. Model reviewers often ask what a sample can support, and here the answer was that the tool could be measured but not yet trusted for that segment.
Stakeholder impact fell on three groups. Applicants with irregular income could be delayed or denied by extraction errors they never see. Underwriters would move from reading files to checking machine output, which changes what they notice and how much they trust the queue. The risk committee carried the fair lending exposure and had to approve the rules for when a person must review. The team proposed a phased rollout: the tool advises on every file, auto-approves only clean salaried applications under a set loan size, and routes all self-employed files to a person.
- Before any pilot runScorecard metrics and go thresholds are fixed and signed off by the risk committee.
- First two weeksOverrides are logged, and every file over the income gap threshold gets a person.
- End of first monthDecision time and error rates by segment are compared against the scorecard.
- End of each quarterFairness review decides whether auto-approval expands, holds, or pauses.
- After enough self-employed outcomesSelf-employed files are reconsidered for automation only with measured results.
Actions taken
- Defined a scorecard before any further pilot runs, with extraction error rate by document type, false approval rate, and decision time by segment, each with a go threshold.
- Required a human to review every file where extracted income differed from the stated figure by more than ten percent, and logged each override with a reason code.
- Set auto-approval to salaried applicants under a fixed loan size, and reviewed a random sample of auto-approved files each week against the source documents.
- Scheduled a fairness review at the end of each quarter comparing denial and delay rates across applicant segments, with authority to pause the tool if gaps widen.
Results
Under the phased plan, the first full month of rollout cut median decision time for salaried files from about two business days to under one, while self-employed files kept their original review pace. The weekly sample found a recurring error in one payroll provider's stub layout, which the vendor fixed within the month. Two overrides pointed to a pattern in scanned notes that the scorecard now tracks. The committee approved expansion to salaried files only, and self-employed applications remain under human review until the segment has enough outcomes to measure.
Questions for discussion
- What minimum sample of outcomes would you require before judging the tool's accuracy for a segment with few historical files?
- Who should have authority to pause an automated tool that is performing well overall but harming one group?
- How would you decide whether an override rate is a sign of tool failure or of underwriter caution?
Learning Resources
Finance CASE STUDIES
China, India, United States, Indonesia, Pakistan, Nigeria, Brazil, Bangladesh, Russia, Japan, Mexico, Philippines, Vietnam, Egypt, Turkey, Germany, United Kingdom, France, Italy, Canada, South Korea, Australia, Spain.