benator

Thirdfort | London, UK | multiple roles | remote (within UK) or hybrid/onsite | full-time

Hi everyone! We're a Series A startup on a mission to protect society from fraud and money laundering using our intelligent Client Due Diligence Platform. With fraud and money laundering skyrocketing, regulated professionals are struggling to keep pace with their compliance obligations. Thirdfort turns compliance into a competitive advantage, offering beautifully secure onboarding for regulated businesses operating across legal and property.

We've already protected over 3 million people through life's big transactions, with a core aim to protect many more. We've spent the last year rebuilding our product from the ground up and are increasingly leaning into AI across the team/system, focusing on technologies that let product-minded engineers solve hard client problems fast and with confidence: Go, Temporal, NextJS and React Native. We expect our engineers to use their hard-won expertise to get deeply involved in product design as much as technical implementation — joining the team is a great opportunity to work with exciting tech and have a real impact on people's lives.

We have the following open positions:

* Lead Software Engineer – we're looking for a strong technical leader to drive one of our product squads. You'll shape architecture, mentor engineers, and ship meaningful product improvements.

* Senior Software Engineer – we're looking for a senior engineer who's excited to own problems end-to-end, from product design through to production.

* Analytics Engineer (Fixed Term Contract) – we're looking for someone to own and improve our analytics models and datasets end-to-end, covering a period of parental leave.

Come take a look at our open roles: https://www.thirdfort.com/jobs/

Thirdfort | London, UK | multiple roles | remote (within UK) or hybrid/onsite | full-time

Hi everyone! We’re a Series A startup on a mission to protect society from fraud and money laundering using a Cloud based SaaS platform. With fraud and money laundering skyrocketing, regulated professionals are struggling to keep pace with their compliance obligations. Thirdfort turns compliance into a competitive advantage, offering beautifully secure onboarding for regulated businesses operating across legal and property. We’ve already protected over 2.5 million people through life’s big transactions, with a core aim to protect many more.

We have the following open positions:

- Security Engineer - we’re looking for a security generalist who’s happy to get stuck into everything from architecture and assessments to policy and compliance.

- Lead React Native Engineer - we're looking for a highly experience React Native engineer with solid mobile experience to take the lead on our new app experience.

Come take a look at our open roles: https://www.thirdfort.com/jobs/

Thirdfort | London, UK | multiple roles | remote (within UK) or hybrid/onsite | full-time

Hi everyone! We’re a Series A startup on a mission to protect society from fraud and money laundering using a Cloud based SaaS platform. With fraud and money laundering skyrocketing, regulated professionals are struggling to keep pace with their compliance obligations. Thirdfort turns compliance into a competitive advantage, offering beautifully secure onboarding for regulated businesses operating across legal and property. We’ve already protected over 2.5 million people through life’s big transactions, with a core aim to protect many more.

We have the following open positions:

- Security Engineer - we’re looking for a security generalist who’s happy to get stuck into everything from architecture and assessments to policy and compliance.

- Senior Software Engineer - we use Go, Typescript, Next.js and Temporal on GCP but are open to people with a different tech stack.

Come take a look at our open roles: https://www.thirdfort.com/jobs/

Thanks and yes, I agree with you! Reality is muddy and complicated and political tendrils reach deeply into all government functions. I would like to ask though: what do you think the author wants us to believe? a) that data is more unreliable because of corrupt influence, or b) data is less reliable because of statistical department cuts and a partisan audience? If it’s b, why mention a? It’s not that I disagree with b or a, just that if you are arguing for one, why mention the other except to say “yeah, this happened but it doesn’t contradict my view because x”

On the first point, ok sure - it may be the case that most aren’t but one is. So… what’s the reader supposed to take away from that? What’s the problem we’re looking at here - malpractice or corruption? Just both but maybe one more than the other? Seems like bad writing to me.

Second point - ok, great. Let’s actually structure the article around that. “We think that cuts in statistical departments, coupled with lower and more complicated survey engagement, have made it harder to rely on the data those departments produce”. Great, nice, coherent argument.

I’m totally not trying to get at you, I just think TFA did a pretty bad job of explaining the problem it’s trying to highlight.

This article is interesting to me mostly because it appears totally incoherent.

> “Western politicians do not appear to be strong-arming the nerds to produce favourable numbers. At the same time, international statistical bodies worry about the example of Dominik Rozkrut, who at the end of last year was mysteriously dismissed as Poland’s chief statistician.”

At the same time as not strong arming these bodies, at least one might be? What is the implication here?

> “Economic “surprises” in rich countries, where the reported data point either beats or falls short of analysts’ expectations, soared during the pandemic. Years later, surprises remain 30% bigger than before it. The confusion represents a reversal of a trend. In 1941 Britain’s…”

How is less trust/revisions in the data today connected with what Britain was doing 70+ years ago? We seem to just have two things said next to each other as if they were related?

Am I just being dumb or is this just ramblings, whether or not you agree with the headline?

Thirdfort | London, UK | multiple roles | remote (within UK) or hybrid/onsite | full-time

Hi everyone from the Thirdfort team! We’re a Series A startup on a mission to protect society from fraud and money laundering using a Cloud based SaaS platform. With fraud and money laundering skyrocketing, regulated professionals are struggling to keep pace with their compliance obligations. Thirdfort turns compliance into a competitive advantage, offering beautifully secure onboarding for regulated businesses operating across legal and property. We’ve already protected over 1.5 million people through life’s big transactions, with a core aim to protect many more.

We have the following open positions:

- Senior DevOps Engineer - cloud hosted using GCP - DevOps Engineer - cloud hosted using GCP - Senior Software Engineer - we use Go, Typescript,Next.js but are open to people with a different tech stack. - Frontend Engineer - we use Go, Typescript,Next.js but are open to people with a different tech stack.

Please see open roles at - https://www.thirdfort.com/jobs/

I think these are broadly reasonable points and when there is no existing security team (I’m joining to set one up) I usually start with going after infra, picking the low hanging fruit and carefully planning out any points of friction with a user base that isn’t used to having a security team. That’s often a journey that involves basic cloud controls, restructuring IAM, bringing in MDM, pushing for license upgrades for key SaaS apps that force you to pay the SSO tax, making sure the WAF and DoS protections are actually doing something useful, documenting the security signals we have and those we need, rolling out and drilling an actionable incident response plan etc. I came from software engineering into appsec, prodsec and then into security management and possibly as a result of that I don’t push for plugging a dependency/static analysis tool into a work item tracking system and fire hosing engineers with CVEs in code paths they never hit. I do want to see that they can keep up with general patching though - can they, on a regular (think weekly/monthly) cadence upgrade their libraries and frameworks to the latest patch version and still ship with quality that week?

But when you look at some key aspects of that infra/biz app security journey at a largely cloud based young business - like taking more control of IAM across SaaS, bringing together activity from those multiple cloud systems and creating alerts that actually matter - that all involves knowing your vendor supports SSO, possibly also SCIM, has logs that contain relevant data that can be exported/streamed into a SIEM. Some of the stuff this standard demands is going to be fairly core to securing business infra. I just get bored talking to vendors that want to wave an ISO cert at me as if that somehow makes it ok they don’t give me access to audit logs.

I think a lot of comments here might be missing the point of this standard - it’s not specifically designed just for startups or to cover general organisation security (like EDR). It’s a product feature oriented checklist that should help short circuit some aspects of supplier security due diligence and establish a set of product security features that any B2B product with ambitions to sell to enterprise customers would benefit from aspiring to, and anyone buying can leverage. That means large multi-product businesses looking to ship an MVP for a new service as well startups with a bright idea but a possibly limited understanding of enterprise IT compliance needs.

I’ve got some experience as Head of Cyber/InfoSec at a couple of startups/scaleups and I see this as potentially useful in a bunch of ways if broadly adopted. It establishes a baseline both for our own products and our suppliers, attests to stuff that actually affects how we integrate with and operate a third party product (ISO 27001 gives me no clue whether you support SSO, have viable logs that I can actually ship to the SIEM etc.) and hopefully simplifies both the due diligence we do on our suppliers as well as that done on us by our customers by allowing us to reduce a good chunk of the product feature questions to “does your product meet the MVSP standard”.

There was a pretty useful discussion of it on the Google Cloud Security podcast a while ago: https://cloud.withgoogle.com/cloudsecurity/podcast/ep114-min...