Let’s continue exploring why bottom-up project planning does not work in FinTech and what you can try as a pragmatic alternative.

As some of you may know, my FinTech journey started first at Amazon and then continued at PayPal.

My biggest lesson learned there: you can be compliant and you can justify and illustrate why and how you are compliant without having to look at every customer or manually approve every transaction and without having 100% certainty.

At Big Tech companies, you don’t have the luxury of saying “I checked every customer and every transaction and I documented my checks, here they are”. You need to build and justify your compliance based on statistics and metrics and technological solutions and probabilities.

Additionally, whatever you do, you cannot be afraid of millions of complaints and millions of fraudsters. I learned to see risks and their consequences in proportion (statistically and pragmatically) and to rely on technology and indirect data when you need to understand and profile your customers and monitor what they do. There are more customers and more transactions than employees, which is why large Big Tech companies cannot survive without scalable compliance.

What many of you may not realize is that when you represent a Big Tech company, a lot of people are biased against you. You may have commercial power in some negotiations, perhaps, but in compliance and customer experience and governmental relationships, a lot of stakeholders will be skeptical, possibly looking at you as a representative of this monopolistic evil force that just wants to make money and take advantage of everyone. The level of scrutiny around what you do is way higher than it would be for a young startup. It means that my arguments had to be even stronger.

Well, my compliance success did not happen overnight…

…If we can rewind the clock back to 2014, that was me working at PayPal right after the PayPal license application in Turkey was rejected. It was my first ever license application and I was devastated because I could not really understand what happened and why, and how I could have prevented it. At the time, I was responsible for compliance and regulatory projects for Central Europe, Russia, the Middle East, and Africa at PayPal. The failure of that project felt personal, even though there were obviously many other people also part of the project team. I could not understand how it was possible that the project that included so many great and experienced people would be rejected, especially given the fact that the company obviously wanted to do a very good job and had a great reputation.

What I later learned is that this “failure” was of the same nature as the failure of the Facebook Libra coin, where you design a project that is too grand and too complex, and too long-term and you don’t test your assumptions early enough. It falls apart under the weight of its own complexity and inability to see early on where the real problem was versus a myriad of non-existential frictions.

Does that sound familiar? Has it ever happened to you too?

I was sad and discouraged… talking to recruiters (instead of hiring a life coach 😁)… I needed some sense of accomplishment, some feeling of being productive and creating progress at my current job despite this setback.

So, I volunteered for a couple of internal projects to be their compliance point of contact. Since I thought I was likely leaving the company anyway, it did not matter that I knew nothing about two-factor authentication, fraud management techniques, forex trading, or online gambling at the time.

One of these projects was the launch of the PayPal One Touch experience in Europe. PayPal introduced a remembered login experience for the user on the same device without requiring the user to re-submit theirs for buying something using PayPal on that device. Coincidentally, it was the time when the requirements around strong authentication and the EBA Guidelines on the security of online payments were just introduced. PayPal launched this project in Europe but forgot to tell regulators about it. Inside the company, nobody actually realized that this was a “new product”. (This gives you an idea that big companies don’t have everything figured out).

The One Touch product hiccup was essentially a classic startup troubleshooting issue, when something happens and it threatens your product’s existence, you have to quickly satisfy a lot of stakeholders and bring about sufficient arguments why whatever you are doing is compliant, not risky, and does not compromise the rights of the customers or their security.

All I had to bring to the table and contribute was some basic understanding of compliance and my common sense. I had zero support and zero competition from peers because nobody from the compliance team wanted to deal with this anyway. It was too late to collect or develop compliance requirements because the product was already out there. The idea was primarily built based on US regulations, and since PayPal is a very US-centric company, if you comply with US regulations, it is most of the time considered good enough.

My job was to understand why the product was considered safe and good from the US perspective, then study the security regulations in Europe, and find if there are some arguments that I could use to justify the way how the product was built and offered.

It took about 3 months and it worked.

In parallel, I was invited to join a few other products related to forex trading and gambling and some other risky verticals.

For all these projects, I was taking one step at a time, offering common sense feedback and compliance guidance to new stakeholders, helping to launch previously untested products and riskier industries, or enabling previously “forbidden” industry segments to get paid through PayPal. At each meeting, I only needed to prepare the bare minimum information, so that they could move forward to the next meeting or next response to the regulator. 

I was never afraid of getting it wrong or making a mistake or missing something because I was sure by the time it gets “real”, I won’t be around, and I won’t be responsible to answer some senior critical authority. Funnily enough, most of those projects got approved and moved ahead at an unprecedented pace, and were blessed by the regulators and auditors, and various risk committees.

Long story short, not only I learned a lot about these growing industries and got more accomplishments than ever before, I built connections with FinTech startup founders, industry leaders, and regulators, and many of them are currently part of my professional network.

In just a few short months, I had enough of a track record, experience, connections, and confidence that I stopped looking for jobs and decided to start my own business because I realized I can consistently get results and don’t need my external environment to be “perfect” or “ready” or “supportive”.

Don’t get me wrong – most external barriers remained the same. Regulators were still conservative and large companies were still slow and there were long waiting times in between. The only thing that changed was my approach – I did not need my next suggestion or next proposal or next response to regulators to be perfect or final, I just responded to questions and shared ideas that made common sense and were no brainers, it required very little research or preparation time, and I was never afraid to get it wrong or lose my face.

Here is the bigger lesson: If you want to keep growing and innovating, but at the same time you need approvals from regulators and banks, and partners, the only efficient way to get things done and keep moving forward is to plan for many iterations and not overspend resources and not hire people before you actually need them.

Creating an arbitrary list of compliance requirements from scratch is a waste of time. For my One Touch project, creating the list of requirements was meaningless because the project was out as is. For the forex, gambling, adult, or gaming verticals, creating the list of requirements was useless too because I did not know much about these industries.

I first learned what these platforms were already doing and why, and where did they see risks, disputes, or other problems. I had to first internalize the risk assessments and experiences shared with me by the people who worked at the possible partner companies and validate their assumptions. It would be incredibly arrogant for me to come in and superimpose some arbitrary requirements in these cases since my stakeholders knew their industry much better.

Never-ever start with a list of requirements is my golden rule.

Now, after sharing with you real-life examples and helping you understand the detriment of pre-imposed bottom-up project planning within FinTech, in the next newsletter within this series, I am going to show you how you can start testing your project ideas early and pragmatically.

Stay tuned!

Prefer to listen to this content on a podcast instead of reading it? – Click here and tune in!