Muhammad Rizki

Writing · Strategy

A boring framework that explained regional fintech

By · · 2 min read

I groaned when I first saw PESTEL. Six boxes on a slide. A few years later those six boxes explained things my code never could.

Hand drawn sketch for "A boring framework that explained regional fintech", with a stick figure saying "six boxes, many surprises"
Sketch by me. The stick figure says: "six boxes, many surprises"

When I first saw PESTEL in my strategy and global economics course, I groaned a little. Political, Economic, Social, Technological, Environmental, Legal. Six boxes on a slide. It felt like something you fill in for an assignment and then forget.

Then I used it to look back at my consulting work in fintech across the region, and it explained more than I expected.

The six lenses

The boxes in PESTEL matter less than the habit of looking outside your own building. Engineers and tech leaders are trained to look inward. Is the code good? Is the system fast? Is the team healthy? PESTEL forces you to ask what is happening in the world that could make all of that irrelevant. (I still think the acronym sounds like a cough medicine.)

What it looks like in practice

When I helped with technology work connected to capital markets in Malaysia, and later in fintech platforms, almost every big surprise came from outside the tech stack.

Political. Government priorities around digital payments shifted which products got attention and which got delayed.

Economic. Currency movements and interest rates changed how much clients were willing to invest in new systems.

Social. Customers moved to mobile faster than many banks expected. Features designed for branch staff suddenly needed to work on cheap phones.

Technological. Cloud adoption, open APIs and real time payment rails changed what "modern" meant almost every year.

Environmental. Less obvious in fintech, but data centre energy use and sustainability reporting began to show up in procurement questions.

Legal. Data residency rules and regulator guidance shaped architecture more than any engineering preference. Where data could live often decided the design before we drew a single box.

That last point deserves more attention. I have seen beautiful architectures rejected because they quietly assumed data could flow across borders. Nobody had asked the legal question early. A twenty minute PESTEL session at the start would have saved weeks.

In banking, compliance works best as a design input instead of an annoying final check, just like latency and cost.

Using it lightly

You do not need a big workshop. I now spend fifteen minutes at the start of a major initiative with a blank page and six headings. For each one, I write one or two things that could help or hurt us over the next two years. Then I ask, "Which of these would change our architecture?"

Usually one or two stand out. Those become explicit assumptions in the design document.

AI adds a new row

AI regulation is moving fast across the region. Rules about automated decisions, data use and accountability are being drafted right now. Any team building AI agents into customer flows should have that on their PESTEL page today, not after launch.

I still groan a little when I open a blank PESTEL page. I just open it earlier now.