> even bad advice
That's putting it politely. Honestly, I think this "handbook" was mostly written by an LLM.
For example, in the immutability section we have this:
"Separating PII from financial data lets you honor erasure without losing the financial history you’re obliged to keep."
Keeping the financial data whilst trashing the customer names, addresses etc. instantly on-demand before the expiry of the relevant time periods is going to leave your entire organisation with a very bad day in the office if a $lawful_body comes knocking for the data to trace a crime.
People going to work in a Fintech should not be relying on a random "Handbook" written by an unknown person in an unknown jurisdiction.
People going to work in a Fintech should only ever work in accordance with their employer's internal handbooks/guidelines/etc which will have been written in conjunction with their firm's lawyers and compliance people to ensure it complies with the laws and reporting requirements in the jurisdiction(s) in which their employer operates.
> Keeping the financial data whilst trashing the customer names, addresses etc. instantly on-demand before the expiry of the relevant time periods [...]
Where does TFA recommend that?
As I see it, it recommends separating PII data you'll eventually have to delete from that you'd probably want to keep forever (including data factoring into your accounting equations/invariants), so that you can delete the former after the relevant recordkeeping periods have elapsed.
> People going to work in a Fintech should not be relying on a "Handbook" written by an unknown person in an unknown jurisdiction.
Sure, but they should also not blindly ignore any ideas and practices presented, or avoid looking beyond their own organization. Ideally, they'll then try to reconcile what they saw with their own knowledge and local regulations etc.
> People going to work in a Fintech should only ever work in accordance with their employer's internal handbooks/guidelines/etc which will have been written in conjunction with their firm's lawyers and compliance people to ensure it complies with the laws and reporting requirements in the jurisdiction(s) in which their employer operates.
Sure, in a world in with only perfect and error-free organizations, that seems like a reasonable approach. But how does one get there without having a conversation such as this one?
> any ideas and practices presented
Unless its your job to architect stuff, in a financial firm you don't go looking around for ideas and practices.
You comply with your employer's practices end of story.
If you like looking up ideas and other people's practices then a heavily regulated environment is probably not the place for you.
> how does one get there without having a conversation
"having a conversation" about new ideas/practices in a regulated firm will involve lawyers and the compliance department.
More than likely that "conversation" will be above most people's pay grade. So you're better off just not wasting your time and adhering to your employer's existing practices.
And for everyone else, its an expensive and high-friction conversation to have if you want to change existing practices.
"Not thinking, just complying" isn't the panacea for good outcomes you make it out to be. You definitely want to limit the amount of excitement, but I've seen many issues caused by legacy formats and practices as well.
> You comply with your employer's practices end of story.
What if you're the employer ("first engineer" etc.), and there are no practices yet? Fintech almost by definition sometimes includes doing things from scratch because some existing solution or incumbent organization isn't working that well anymore.
> Unless its your job to architect stuff
Which seems to be the target audience/scenario for TFA.
> What if you're the employer ("first engineer" etc.), and there are no practices yet?
In that scenario the practices will still come first. You're not going to be doing any coding or systems engineering until you've got compliance signed off. You're going to be spending lots of time with lawyers and compliance people.
> Fintech almost by definition sometimes includes doing things from scratch
Yes, but cut through the noise of the typical Fintech fancy website and app and you're still staring straight down the barrel of spending 80% of your time on regulatory compliance.
Try as you might there are only so many ways you can re-invent the wheel for dealing with hard-facts legislation.
Please show me the regulation that tells me whether to use big decimals or integers in my internal monetary amount representation. Regulations usually care about outcomes (sometimes high, sometimes low level); they often don't tell you how to technically achieve them.
And if your lawyers and compliance people are actually telling you that you can absolutely not do any financial processing yourself, that the only possible way to be compliant is to license <incumbent product xyz> (unfortunately only available in COBOL) etc., you might not actually be working in a fintech, or at least not in the kind this guide seems to be targeted to.
Frankly, this kind of attitude is exactly why banking and payments is as fossilized as it is in some countries, and why fintech is eating their lunch in many cases. There has to be a balance between trying new things and doing what everybody else is already doing.