Automated Fake Account Detection at LinkedIn

Ideas you will meet

Distributed Systems

Consensus, time, failure and the fundamentals of scale-out.

Machine Learning Systems

Recommendations, ranking, feature stores and serving models at scale.

What we already know about this

Our own lessons on these ideas. Read them here before you start, so it makes sense.

• Core Concepts: How Things Actually Work · 8 minWhere online payments are headingInstant payments, open banking, wallets and tokens, stronger authentication and new money types: what is changing and what it means for system design.Read hereClose

  Why this matters to a system designer

  Payment systems are changing from card-centric, batch and slow, to real-time, account-based and programmable. Each trend changes your architecture, so it helps to know the direction. The items below describe trends in the industry, not predictions about any one product.

  Trend 1: instant, always-on payments

  Many countries now run instant payment schemes: UPI (India), Pix (Brazil), Faster Payments (UK), SEPA Instant (Europe), FedNow (United States). Funds move between bank accounts in seconds, at any hour, including weekends.

  Design consequences:

  • Settlement is final and fast, so fraud checks must happen in real time, before sending.
  • Your system must run 24/7 with no overnight batch window.
  • Confirmation arrives asynchronously, so you need pending states, webhooks and reconciliation (see the payment design lesson).

  Trend 2: open banking and account-to-account payments

  Regulations such as the EU's PSD2 and similar rules elsewhere require banks to offer APIs so that, with the customer's consent, a regulated third party can see account data or initiate a payment directly from the bank account. This enables card-free checkout at lower cost.

  Design consequences: you integrate with consent flows and bank-specific quirks, handle redirects and expiring consents, and treat the bank as an unreliable dependency.

  Trend 3: wallets, network tokens and tokenisation

  Apple Pay, Google Pay and similar wallets store a token instead of the card number. Card networks also issue network tokens for saved cards that can be refreshed when a card is reissued. A stolen token is of little use elsewhere.

  Design consequences: store tokens, not card numbers; handle lifecycle updates (card replaced, token suspended); and rely on the provider's PCI-compliant fields.

  Trend 4: stronger authentication and less fraud

  Strong customer authentication (for example 3-D Secure 2) adds a risk-based extra check only when needed. Passkeys and device biometrics replace passwords and one-time codes. Machine learning scores transactions in milliseconds using device, behaviour and network signals.

  Design consequences: payment flows need extra steps and failure handling, and a risk engine on the critical path with tight latency budgets.

  Trend 5: embedded finance and flexible credit

  Payments are built into other products (marketplaces, software platforms, ride apps), and pay later options split a purchase into instalments. Platforms handle onboarding of sellers, split payouts and compliance.

  Design consequences: multi-party ledgers, payouts, KYC and risk for sub-merchants, and refunds that touch several accounts.

  Trend 6: richer messages and faster cross-border

  The ISO 20022 standard brings structured, data-rich payment messages to banks worldwide, improving reconciliation and screening. Cross-border networks are working to shorten the chain of intermediaries and improve tracking (see the cross-border lesson).

  Trend 7: new forms of money

  Stablecoins and central bank digital currencies (CBDCs) are being explored, piloted or regulated in different places. Treat them as additional payment rails with their own settlement, custody and regulatory models, not a replacement for the fundamentals.

  A ledger-based wallet on a blockchain keeps balances as shared, append-only records that many parties verify, which can shorten settlement. The trade-offs are throughput, finality rules, regulation and the loss of simple reversal, so treat it as another rail with its own failure modes, not a replacement for the ledger discipline above.

  The payment rails side by side

  100%

  Figure SDA-CORE-21-1 · Several rails into one payment service · © forcsguy.com

  What stays the same

  Whatever the rail, the engineering core is stable: idempotency, a double-entry ledger, a clear state machine, asynchronous confirmation, reconciliation, strong security, and observability. Build those well, and adding a new payment method becomes an integration, not a rewrite.

  Real-world reading

  Related reading

  • Stripe's payments APIs: the first 10 yearsStripeCase Studies
  • Stripe Engineering BlogStripe engineers · StripeBlogs
  • Square BlogBlock (Square) engineers · Block (Square)Blogs
  • Klarna BlogKlarna engineers · KlarnaBlogs

  Show 6 moreShow fewer

  • Coinbase BlogCoinbase engineers · CoinbaseBlogs
  • Nubank BlogNubank engineers · NubankBlogs
  • Kraken BlogKraken engineers · KrakenBlogs
  • Capital One BlogCapital One engineers · Capital OneBlogs
  • Automated Fake Account Detection at LinkedInLinkedIn engineers · LinkedInCase Studies
  • Squarespace Engineering BlogSquarespace engineers · SquarespaceBlogs

  Open this lesson with its quiz and exercise