As a reminder, this was the era of the early iPhones and the first MacBook Air [2] — tech was mature enough, but not yet overcrowded with VCs.

[1] https://www.federalreserve.gov/monetarypolicy/bst_recenttren...

[2] https://web.archive.org/web/20080223071127/http://www.apple....

I actually find it intriguing that you work for Stripe and therefore presumably understand the content of the article you're referring to, but continue to pretend that the SQL examples somehow have value for fraud prevention purposes.

OK, let's take a look at this SQL. I took a random example:

> select

> date_format(date_trunc('week', d.created), '%Y-%m-%d') as week_iso,

> r.rule_id,

> r.predicate,

> count(distinct d.charge_id) as count_total_charges

> from rule_decisions d

> join radar_rules r on r.rule_id = d.rule_id

> where d.created >= date_add('month', -3, current_date)

> and d.action = 'block'

> group by 1,2,3

> order by 1;

The example above is about grouping rule decisions by Radar rules for performance optimisation, and has no value for any other fraud prevention techniques.

Overall, the test is simple: the link is called 'How to continuously improve your fraud management with Radar for Fraud Teams and Stripe Data' and the article itself is in the 'Product resources' category. It is not a general example, and using Stripe is necessary to get any value from it.

All of this makes the article marketing material, and given that you're employed by this company, that must be disclosed.

If you're affiliated with Stripe as an Integration Engineer, that should come before the marketing link to Stripe website.