The two-hour task that vanished.
Every 30 to 45 minutes, Shannon stopped what she was doing. Opened the Investec banking portal. Navigated to the first of three client-facing accounts. Downloaded the statement. Uploaded it to the right folder. Then the second account. Then the third. Then she went back to her actual work — until it was time to do it again.
She did this all day, every working day. If she got behind — a meeting ran over, the phone rang — clients raised tickets because their deposits weren't showing up in the system. If it was after 5pm, or a Saturday, or a public holiday? Nobody was doing it at all. Those deposits just waited until Monday morning.
Two hours a day. Every day. For something a computer should obviously be doing.
The quiet cost of the obvious
This is the kind of problem that hides in plain sight. It's not dramatic. It doesn't produce a crisis — just a steady drain. Two hours of someone's day, every day, on a task that requires zero judgement, zero creativity, zero human insight. Log in, download, upload. Log in, download, upload.
Multiply it out: 2 hours × 22 working days × 12 months = 528 hours a year. That's 66 full working days. Thirteen working weeks. A quarter of a person's year, spent dragging files between two systems.
What happened in April
In early April 2026, the innovation team picked up this problem. Johan and Tjaardt Klue — the Overclocked team — sat down with AI-assisted tooling and started building.
Two active development days later, the service was in production.
Not a prototype. Not a demo. A production service — monitored, tested (153 tests), documented (five architecture decisions, ten delivered documents), running in a container, polling the Investec banking API every 15 minutes, 24 hours a day, 7 days a week.
How it works
Every 15 minutes, the service authenticates with Investec's banking API, fetches credit transactions for three accounts, filters out anything it's already delivered (using fingerprinting stored in Redis), formats the data into the exact CSV the Deposit Allocation tool expects, and delivers the file via secure transfer — written first as a temporary file, then renamed, so the receiving system never reads a half-finished document. If a delivery fails, it retries next cycle automatically.
In Shannon's words
Johan and Tjaardt assisted with setting up an API/SFTP link to Investec, which has made a significant difference to my daily workflow. Previously, I had to manually log into the Investec bank portal every 30–45 minutes to download bank statements for each of the 3 client-facing bank accounts and then upload them into their respective Investec folders. This was very time-consuming and difficult to keep up with consistently — if I didn't get to it in time, clients would create tickets because their deposits weren't being reflected timeously.
With the API/SFTP integration now in place, the bank statements feed automatically and directly into my Deposit Allocation tool. I no longer need to log in manually at all.
This has saved me approximately 2 hours per day, freed me up to focus on other tasks, and reduced the number of Investec client tickets related to deposit visibility.
Before and after
Before
- ~2 hours of manual work per day
- Log in every 30–45 minutes
- 3 accounts, downloaded one by one
- Business hours only (weekdays)
- Frequent client tickets
- High risk if missed
After
- 0 hours of manual work
- Automated every 15 minutes
- All 3 accounts, in parallel
- 24/7/365 — nights, weekends, holidays
- Minimal client tickets
- Self-healing — retries automatically
Built properly, built fast
The service took 10 business days from start to production — 2 of those were active development days; the rest was review, testing and deployment. It was built by two developers — Johan and Tjaardt Klue, the Overclocked team — working with AI-assisted tooling, the same kind of AI-accelerated delivery you'll see across the innovation team's work.
The quality bar wasn't lowered for speed: 153 tests. Five architecture decisions formally documented. Per-account error isolation. Redis-backed deduplication that survives restarts. Production observability through Prometheus metrics and Elastic APM. Atomic delivery that prevents partial reads. A backfill endpoint for disaster recovery.
This wasn't "move fast and break things." It was "move fast and build things properly."
What this really means
This story isn't really about bank statements. It's about what happens when you point a capable team at the right problem.
Every organisation has its Shannon — someone spending hours a day on a task that a well-built service could handle permanently. The cost isn't just the hours; it's what doesn't get done while those hours are consumed. It's the weekends and evenings where the process simply stops.
The Investec Deposit Feed is one example of what the innovation function at Purple produces: identify a high-pain, highly automatable task. Build the right solution, fast, to a production standard. Measure the impact. Move on to the next one.
Got a process like Shannon's?
If someone on your team is spending hours a day on something a service could handle — that's exactly the kind of problem the innovation team picks up. Bring it to the Innovation Registry and it gets a fair hearing.
Field notes
Real accounts from people using this in their week — see all field notes across the series.
This has saved me approximately 2 hours per day, freed me up to focus on other tasks, and reduced the number of Investec client tickets related to deposit visibility. I no longer need to log in manually at all.