Hani Yacoub Data & risk analyst

Data & Risk Analyst / Berlin

I built the platform, the dashboards, the models and the forecasts that fraud decisions run on.

legitimate flagged ring

Six years across energy, automotive, fashion and cloud. Now at AWS, on fraud prevention, where a wrong call costs money in both directions. Miss the abuse and it is expensive. Shut down a real customer and it is worse. So I measure both sides before anyone acts.

6+ yrs
In data, risk & analytics
4 sectors
Energy · auto · fashion · cloud
18 cases
Platforms, dashboards, models, forecasts
Scroll
Try it yourself

Anyone can catch more abuse. The craft is the cost of catching it.

Move the detection threshold. Catching more abuse is the easy part. Drag it up and watch the first bar climb. The hard part is the second bar, because every step too far flags real customers. The job is living in the narrow band where one is high and the other is near zero.

Abuse caught
86%
Legitimate customers flagged
2.4%
Lenient Aggressive

Who is doing this

I am Hani. Based in Berlin, six years in data.

The short version is four habits and the projects that came out of them.

  1. 01

    I start with the false positives.

    A missed fraudster costs money. A wrongly closed customer costs money and trust, and turns up weeks later as a support ticket nobody connects to the rule that caused it. So the carve-outs get built before the bulk action does.

    See how the carve-outs work
  2. 02

    Then I build whatever the answer depends on.

    Usually that is infrastructure nobody asked for. Two company databases sat behind two different logins with a slow sign-in on every query, so I put them behind one interface and made queries about ten times faster. Every other project I have shipped runs on it.

  3. 03

    I do not trust a number until something has tried to break it.

    Headline figures get attacked before they reach anyone. On its founding case it caught a silently truncated query and moved the headline by 69 percent. Catching that in draft beats being wrong in a room full of stakeholders.

  4. 04

    And the same instinct works outside fraud.

    Before AWS I scored which customers were worth calling at an automotive marketplace, cut a Zalando pipeline from 34 minutes to a few, and put a euro figure on refund abuse across six markets. Same job underneath, different domain on top.

    See the scoring work
Where I have worked
  1. 2020 to 2021 Statkraft Energy · Quantitative analyst intern, energy markets
  2. 2021 to 2024 AUTO1 Group Automotive · Data analyst, customer acquisition
  3. 2024 to 2026 Zalando Fashion e-commerce · Senior product analyst, risk & abuse
  4. 2026 to present AWS Cloud · Payments & fraud prevention
Studied
  • MSc Business Management SRH Berlin University of Applied Sciences
  • Data Engineering with AWS Udacity nanodegree
  • ML engineering, self-directed 12-month curriculum, ongoing: built from scratch before reaching for libraries
Tools
  • Python
  • SQL
  • PySpark
  • Databricks / Spark · Delta
  • Amazon Redshift
  • XGBoost / classifiers
  • SageMaker
  • LLM agents · MCP
  • Streamlit · Plotly
  • QuickSight · Tableau
  • sigma.js · graph analysis
Built on my own time

Two products you can go and use right now.

Selected work

Eighteen cases. Each one starts with a number and ends with a decision.

15 cases
  1. 01
    AWS Ring detection · graph analysis

    Making fraud rings visible in a whole population

    Groups of accounts working together are invisible one at a time. Drawn as a map of who is connected to whom, they stand out as clusters. Real customers do not get dragged in with them.

    Tested against a group already confirmed by hand, the map put every one of its members in a single cluster. Something invisible one account at a time became a group an analyst could act on in minutes. It then scaled from one region to the multi-million-account global population.

    Read the case
    Whole-population relations graph
    100% of a known ring in one cluster
    flagged ring legitimate broker
    Hover any dot to isolate the group it belongs to. Toggle to hide the ordinary customers and leave only the suspicious groups. Representative shape. The live version runs on confidential data.

    A line means two accounts share something meaningful, weighted by how rare that thing is and how strongly it actually predicts fraud. The larger dots are the accounts that bridge two groups, which are often the ones worth acting on first.

  2. 02
    Zalando Data engineering

    Cutting a fraud pipeline from a coffee break to a glance

    A refund-analysis Spark job that set the pace of every leakage question asked through it, cut from ~34 minutes to minutes without a bigger cluster.

    Cut a core refund-analysis pipeline from ~34 minutes to minutes, mostly by reading only the needed columns and filtering on partitions before any data moved.

    Read the case
    Pipeline runtime -85%
    Brute-force reads
    ~34 min
    Tuned layout
    minutes
    Same analysis, same cluster. The change was in what the job read, not what it ran on. Only the ~34-minute baseline is measured. The after bar is sized illustratively against it to show the shape.
  3. 03
    AUTO1 Group Customer analytics

    Scoring which customers were worth the call

    Before the fraud work, the same ranking problem: a large business customer base, finite calling capacity, one score deciding the week.

    Replaced flat outreach across a large business customer base with a ranked call queue. Finite calling capacity went to the accounts carrying the most value.

    Read the case
    What a value rank does to a week of calling relative value carried
    • Top-ranked accounts
      100
    • Next band
      58
    • Middle of the base
      31
    • Long tail
      12
    Illustrative magnitudes, since the live score runs on AUTO1's customer data. What the work established is the ordering, and that the base was not evenly valuable. Flat outreach treats these four bands as though they were the same bar.
    Show the data table
    What a value rank does to a week of calling: ranked.
    CategoryValue (relative value carried)Note
    Top-ranked accounts100Worked first, because the rank put them first rather than because they called in.
    Next band58
    Middle of the base31
    Long tail12
  4. 04
    AWS BI · reconciliation

    The first reconciled fraud view on a brand-new AWS region

    An org-wide fraud-and-revenue dashboard for AWS's European Sovereign Cloud, whose credibility came from correcting two of its own headline numbers.

    Delivered the first unified, reconciled fraud view on a brand-new AWS region, corrected a flattering ~98% automation headline down to an honest ~12 to 13%, drove a revenue undercount to under 1%, and made flag-to-shutdown speed measurable at ~1 day on average.

    Read the case
    Reported model-automation rate -87%
    Claimed (lazy attribution)
    ~98%
    Measured (enforcement path modelled)
    ~12 to 13%
    Automated rules disambiguated from analyst bulk actions. Accuracy over a flattering headline.
  5. 05
    AWS False-positive prevention

    Catching the ring without breaking the customers inside it

    A seven-figure flagged account turned out to be reserved-but-unused GPU capacity, not fraud. Reversals like that became the carve-out gates every bulk shutdown now passes through.

    Fraud calls reversed on legitimate accounts, including a seven-figure account proven to be reserved GPU capacity, then hardened into a standing control: bulk ring actions catch the abuse with ≈0 collateral, every wave ships with its legitimate-impact exposure priced for sign-off, and known false positives are catalogued so they're never re-flagged.

    Read the case
    A bulk ring action, with the carve-out gates in front of it
    Ring accounts actioned Ring caught
    Legitimate accounts wrongly shut ≈ 0 collateral
    Hard-identifier-only matching plus a pre-action legitimate-impact carve-out keep real customers out of the wave.
  6. 06
    AWS Enforcement automation

    An enforcement job trusted to run itself, daily, in production

    Shutdown authority handed to a scheduled job on AWS's European Sovereign Cloud partition, with every safety property structural rather than procedural.

    Eight ordered safety gates, a hard kill switch, and a shadow twin measuring precision continuously now stand between a candidate account and closure. Zero policy thresholds are hardcoded.

    Read the case
    Eight ordered gates before any shutdown 8 in order
    1. Population scoping Defines the candidate pool a run may consider at all.
    2. Unlabelled filter Restricts the pool to unlabelled accounts.
    3. Confirmed-fraud linkage Weighted, and only over non-placeholder hard identifiers.
    4. Not already enforced Drops accounts an earlier action already covered.
    5. Account-age floor A minimum account age is required to proceed.
    6. Carve-outs → review Legitimate-customer patterns route to human review, never to closure.
    7. Enforce-time re-check State is re-verified at the moment of action, not just at selection.
    8. Ranked per-run cap Ranked and capped, so one run has a bounded blast radius.
    Order carries the meaning: the carve-out gate only ever sees accounts that cleared the five before it. Runs daily in production under a hard kill switch.

    Candidate accounts enter at gate one. Per-gate survivor counts are not published.

    Show the data table
    Eight ordered gates before any shutdown: every stage in order.
    Stage#What it checks
    Population scoping1Defines the candidate pool a run may consider at all.
    Unlabelled filter2Restricts the pool to unlabelled accounts.
    Confirmed-fraud linkage3Weighted, and only over non-placeholder hard identifiers.
    Not already enforced4Drops accounts an earlier action already covered.
    Account-age floor5A minimum account age is required to proceed.
    Carve-outs → review6Legitimate-customer patterns route to human review, never to closure.
    Enforce-time re-check7State is re-verified at the moment of action, not just at selection.
    Ranked per-run cap8Ranked and capped, so one run has a bounded blast radius.
  7. 07
    AWS Signal economics

    No signal ships until its false positives are priced

    Device fingerprint was missing from the Fraud Relations model's linkage signals, and young-domain registrations were going unchallenged. Adding either meant writing down what it would cost in customers wrongly linked.

    34% more disputed dollars caught from one ensemble feature, and hundreds of abusive accounts caught at near-zero collateral from one rule. Both carry a false-positive bill priced per signal rather than assumed.

    Read the case
    The domain-age rule in production
    Abusive accounts caught Hundreds
    Legitimate customers hit Near zero
    Multi-condition logic bounded by explicit carve-out exposure analysis.
  8. 08
    AWS Probabilistic forecasting

    Forecasting fraud load, never as a single line

    A 40,000-run Monte Carlo built to size a new region's review queue inverted the premise it was commissioned to support: volume tracks operational decisions, not fraud inflow. Its companion engine forecasts compute load so the as-is and intervention scenarios separate on measured behaviour rather than assumption.

    Replaced point-guess forecasting with p10/p90 thresholds whose coverage was measured rather than assumed, plus P50/P90 cones on both compute scenarios, and produced the counter-intuitive, defensible finding that operational decisions, not fraud inflow, drive queue volume. One ring was behind 71% of every task ever queued, with uncaught fraud sized two independent ways.

    Read the case
    Share of all tasks ever queued, from one ring of every task in the queue's history
    • One coordinated ring 71%
    • Everything else 29%
    Concentration this extreme is what disqualified fraud inflow as the planning variable. The distribution, not intuition, is what settled it.

    Kept inside the baseline on purpose, after a ring-excluded companion scenario showed how different the forecast looks without it. A capacity plan should be conservative, and rings recur.

    Show the data table
    Share of all tasks ever queued, from one ring, of every task in the queue's history.
    SegmentShare
    One coordinated ring71%
    Everything else29%
  9. 09
    Zalando Fraud measurement · counterfactual

    A euro figure on the fraud that survived, and controls that can't flatter themselves

    Remaining Fraud Damage sizes the logistics refund leakage that slips past every control, in euros, per segment, per market. Holdout and counterfactual framing then stops the controls taking credit for reducing it.

    Produced the first euro-denominated estimate of logistics refund leakage surviving existing controls, by customer segment and across six markets, refreshed weekly and monthly for business reviews, and replaced flattering before/after reads with holdout / counterfactual evaluation so prevented damage was separated from remaining damage.

    Read the case
    Refund / damage rate by customer value segment refund/damage rate (illustrative)
    A/VIP benchmark segment rate trusted A/VIP floor → higher-risk value segments
    Each segment's excess over the trusted A/VIP benchmark, applied to its GMV, is the leakage estimate. Shape is illustrative. Live values come from the model.

    Remaining Fraud Damage = Return Damage + Delivery Damage, as a share of GMV, tracked across DE · NL · BE · FR · IT · CH weekly and monthly.

  10. 10
    Independent Developer tools · AI orchestration

    Renitor: your coding task outlasts any one AI agent

    A published VS Code extension where an unfinished coding task survives the agent that started it, behind a deterministic safety layer rather than a model's judgment.

    A coding task now moves across 11 coding agents and fails over across 25 models without being re-explained, behind a deterministic command-safety layer and zero telemetry.

    Read the case
    What a handoff carries, in the order it is assembled 7 in order
    1. Repo context Captured from the repo, not re-typed by hand.
    2. Git state The branch and the diff travel with the task.
    3. Decisions made What was already settled travels with the task.
    4. What is broken The failing test goes across too.
    5. Next steps What comes next is recorded, not reconstructed.
    6. Continuation prompt Paste-ready, and it works across 11 coding agents.
    7. Handback Work done elsewhere re-injects natively into Claude Code.
    Order is the point: the continuation prompt is only useful because the five fields before it are already filled, and the handback closes the round trip so the original session knows what changed.
    Show the data table
    What a handoff carries, in the order it is assembled: every stage in order.
    Stage#What it checks
    Repo context1Captured from the repo, not re-typed by hand.
    Git state2The branch and the diff travel with the task.
    Decisions made3What was already settled travels with the task.
    What is broken4The failing test goes across too.
    Next steps5What comes next is recorded, not reconstructed.
    Continuation prompt6Paste-ready, and it works across 11 coding agents.
    Handback7Work done elsewhere re-injects natively into Claude Code.
  11. 11
    Independent SaaS · deterministic validation

    Preflights: the check before the import that can't be undone

    Pre-import QA for Shopify catalogs: a deterministic engine that flags variant deletion and silent product overwrites before a supplier file touches a live store.

    A deterministic pre-import safety check that catches the two irreversible Shopify mistakes, variant deletion and handle collisions, with zero store access, in seconds.

    Read the case
    What a free CSV validator checks 2/5 covered
    • Formatting
    • Column layout
    • Variant-delete risk gap
    • Handle collisions gap
    • Live price conflicts gap
    Free validators read the file. The dangerous mistakes need it read the way Shopify will.
  12. 12
    Zalando Root-cause analysis

    Five reasons a parcel-missing refund happens, and a record that names none of them

    A refund record says what was claimed, never why. Telling a delivery failure from abuse decides the fix.

    Reframed parcel-missing refunds from a single fraud reading into five causes that have to be separated, because an operational cause and an abusive one need opposite fixes.

    Read the case
    What a parcel-missing refund record actually carries 4/5 covered
    • That a manual refund was issued
    • The manual refund reason recorded
    • The Salesforce case it arrived through
    • The order behind it
    • Why the parcel went missing gap
    The record is complete on everything except the one field nobody can log. Cause is not a column, so it has to be established from evidence.
  13. 13
    AUTO1 Group Churn and retention

    Which accounts were leaving, and which losses were worth fixing

    Two scores for two questions: which business customers were at risk of leaving, and which points of customer drop-off carried enough revenue to be worth working.

    Churn risk became a ranked outreach priority for the commercial team. Every drop-off point carried a quantified revenue upside, which is what identified the highest-impact retention opportunities.

    Read the case
    Where the base drained across the customer relationship share still active (illustrative)
    still active time as a customer
    Illustrative shape, since the live analysis ran on AUTO1's customer data. What the real work established is that drop-off concentrated at identifiable points in the relationship, which is what let a revenue figure be attached to each one.
  14. 14
    Zalando Metric ownership

    Owning the fraud numbers, and proving which moves were real

    I owned the weekly and monthly fraud numbers. The hard part was ruling out who was shopping that week.

    Owned the fraud metric set for weekly and monthly business reviews across six European markets. Every move got read against population mix, base rate and soft exclusions before anyone reported it as a change in fraud.

    Read the case
    What a moved number clears before it is read as fraud 4 in order
    1. Comparable population Same markets and same customer segments as the period it is measured against. A different population is a different measurement.
    2. Soft exclusions accounted for Cases kept out of the count change the denominator without ever appearing on the chart.
    3. Base rate stable How much fraud there was to find at all. More fraud around raises the flagged rate with no change in detection.
    4. Now read the move as fraud Only what clears the first three gets reported as a change in fraud, and only that is worth acting on.
    No counts are published here. The order is the argument, because a base-rate check on a population that was never comparable settles nothing.

    Applied to suspicious rate, detected rate and steer rate, weekly and monthly, across the top six markets: Germany, the Netherlands, Belgium, France, Italy and Switzerland.

    Show the data table
    What a moved number clears before it is read as fraud: every stage in order.
    Stage#What it checks
    Comparable population1Same markets and same customer segments as the period it is measured against. A different population is a different measurement.
    Soft exclusions accounted for2Cases kept out of the count change the denominator without ever appearing on the chart.
    Base rate stable3How much fraud there was to find at all. More fraud around raises the flagged rate with no change in detection.
    Now read the move as fraud4Only what clears the first three gets reported as a change in fraud, and only that is worth acting on.
  15. 15
    Zalando Risk decision data

    Joining every risk decision to what happened next

    An abuse decision nobody can join to its outcome cannot be evaluated. I built the join, login to feedback.

    Produced one joined dataset covering login, order, assessment, decision, steering and feedback. Read the legacy and current sources together under one label mapping, so older records stayed readable next to current ones.

    Read the case
    The chain the joined dataset runs along, in order 6 in order
    1. Login Authentication events. Who signed in, and when.
    2. Order placed Order-placed events with order-position rows, so the basket is visible and not only the order.
    3. Risk assessment What the abuse-protection platform made of it. Read from the legacy source and the current one.
    4. Risk decision What was actually decided about that assessment.
    5. Steering decision The customer-risk steering tables. How that customer was handled from then on.
    6. Steer feedback The feedback recorded against that steer. Return steering carries its own feedback, joined alongside.
    Each stage only sees what the one before it produced, which is why the order is the design and not a presentation choice. No counts are published here. The purpose of the chain is evaluation: how abuse-protection decisions performed, and where fraud damage remained.

    Customer dimension data, sales channel, route-accessed events, and a table mapping fraud rules to fraud domains join alongside the chain as context.

    Show the data table
    The chain the joined dataset runs along, in order: every stage in order.
    Stage#What it checks
    Login1Authentication events. Who signed in, and when.
    Order placed2Order-placed events with order-position rows, so the basket is visible and not only the order.
    Risk assessment3What the abuse-protection platform made of it. Read from the legacy source and the current one.
    Risk decision4What was actually decided about that assessment.
    Steering decision5The customer-risk steering tables. How that customer was handled from then on.
    Steer feedback6The feedback recorded against that steer. Return steering carries its own feedback, joined alongside.