Skip to content
Mike Reams
← Blog

Post ·

A Raspberry Pi ATM: Lessons From a 2018 FinTech Hackathon

A Raspberry Pi, a 7-inch screen and one question: what else could an ATM do? What a third-place 2018 FinTech hackathon taught me about data and opt-in.

LinkedIn (opens in a new tab)X (opens in a new tab)Facebook (opens in a new tab)Email
Diagram: location data (demographics, places), card transactions (purchase patterns) and events by ZIP code feed a recommender using collaborative filtering and k-means. The recommender drives an ATM screen built on a Raspberry Pi with a 7-inch display, which serves members (tickets, offers, directions) and lets non-members opt in for fee-free cash, becoming new customers. The data also informs where to pilot, by demand and points of interest. A callout reads: opt-in first, engine second. Footer: 3rd place, Pitney Bowes, RCG and TAG FinServ/FinTech hackathon, 2018.Diagram: location data (demographics, places), card transactions (purchase patterns) and events by ZIP code feed a recommender using collaborative filtering and k-means. The recommender drives an ATM screen built on a Raspberry Pi with a 7-inch display, which serves members (tickets, offers, directions) and lets non-members opt in for fee-free cash, becoming new customers. The data also informs where to pilot, by demand and points of interest. A callout reads: opt-in first, engine second. Footer: 3rd place, Pitney Bowes, RCG and TAG FinServ/FinTech hackathon, 2018.

In November 2018, a month after a Microsoft/TAG hackathon, I was back at it: a FinServ/FinTech hackathon in Alpharetta, hosted by Pitney Bowes, RCG Global Services and the Technology Association of Georgia (TAG). My team placed third, with an ATM that did more than hand out cash.

The brief

The sponsors set four business problems, and teams had two days to build. Judges scored functionality, usability, impact, viability, innovation and speed to market, plus a discretionary score of their own. We took the ATM problem: how could a bank get more out of a network of machines it already owns?

What we built

An ATM already sits in a known place, and it already knows who walked up. We joined location and demographic data with a public set of card transactions and a feed of upcoming events by ZIP code, then ran a recommender over it (collaborative filtering plus k-means clustering) to decide what to show each person.

  • Members saw offers that fit them: tickets to events nearby, coupons for nearby retailers and directions to get there.
  • Non-members could opt in, and in exchange got cash without the out-of-network fee. For the bank, that is customer acquisition at a machine it already owns.

For the demo I built the ATM itself: a Raspberry Pi with a 7-inch LCD, running a “Start Banking” screen that served those recommendations. Judges could stand in front of it, which beats any slide that begins “imagine an ATM.”

What carried over

  • Location turns data into a decision. Transactions say little on their own; add where people are and what is near them, and they tell you what to offer and where to pilot first.
  • Every new channel is a data agreement. Showing someone an offer based on their demographics only works if they asked for it. Opt-in comes first; the engine comes second.
  • Build the prop. A working screen on cheap hardware made the idea real in a way an architecture diagram doesn't, and I say that as someone who draws architecture diagrams.
  • Read the scorecard. Speed to market was scored right alongside innovation. A clever idea a bank can't pilot next quarter loses points, and it should.

Looking back from 2026

If I rebuilt it today, I'd start with the phone rather than the screen. The banking app already knows who you are, and the ATM becomes one more surface for the same consent and the same recommendations. The part I wouldn't change is the order of operations: earn the opt-in, then personalize.

We took third place. The prize was split across the team; the lesson about opt-in has paid out for longer.