Researching this and cannot find a clear answer. Extensions run client side, so nothing shows in the case system logs.
Has anyone found a way to detect it, or is this invisible in practice?
Worth tracking for anyone on the payments side. Pre-transfer name-to-account matching, combined with screening and fraud scoring, is increasingly being embedded directly into international transfer routing rather than run as a separate step before submission.
The reason it matters is where the friction lands. A name check done before the payment is submitted can stop an authorised push payment fraud at the only point where the member can still change their mind. one after submission, it is a reconciliation exercise.
The hard part is not the matching logic. It is the tolerance. Legal names, preferred names, married names, initials, transliterations and business trading names all produce mismatches that are entirely innocent. Tighten the threshold and you block legitimate payments and train members to click through warnings. Loosen it and the control stops meaning anything.
There is also the question of what a warning is actually for. If a member sees a soft mismatch warning and proceeds anyway, has the institution discharged something, or has it just moved the liability onto the member?
For people running at a credit union or community bank: what does your name-match tolerance look like in practice, and do you track how often members override a mismatch warning and then report fraud?
Published 9 September. It is the first time FATF has examined online and illegal gambling in this much detail, alongside casinos and video gaming.
The headline finding is the size of the unlicensed market. In a lot of jurisdictions it matches or beats the regulated one, which means the sector's AML controls only cover part of what is actually happening.
The new risk indicators are the practical output. They cover multiple accounts and payment methods under different identities, mismatches between customer details and payment details, and ownership structures that obscure who actually benefits. Also flagged is the surrounding ecosystem, since platforms depend on social media, digital marketplaces and payment services that often sit outside the regulatory perimeter.
The indicator that looks hardest to operationalise is the identity mismatch one. Catching the same person behind several accounts requires linking across accounts, and plenty of platforms deliberately do not do that, either for privacy reasons or because the data sits in separate systems.
For anyone working in gambling compliance or supervising it: which of these indicators can you actually detect today with the data you hold, an which would need a platform change? And has anyone built cross-account linking that survived a privacy review?
Proposed on 17 September. Three tiers. Under 13, no social media account. 13 and 14, a limited account that sits under a parent or guardian account. 15 and over, a normal account.
Scope goes beyond social media. Video sharing platforms, online games, and AI companions and chatbots are all in. There is a safety-by-design section too, covering addictive design, recommendation feeds, infinite scroll, reward loops and notifications during sleep hours. Penalties reach 6% of global annual revenue.
The part nobody has answered is how a platform proves a 12 year old is 12. The Commission is pointing at its own open-source age verification solution, due by the end of the year, with EU Digital Identity Wallets as the long-term answer. Both move the check off the platform, which helps with data minimisation, but neither exists at scale yet.
There is also the family link problem. A parent-linked account for 13 and 14 year olds means verifying not just two ages but a relationship between two people. That is harder than age on its own and it gets very little attention in the proposal.
For people following EU digital policy: is the wallet realistically going to be ready for this, and what happens in the gap between the law and the infrastructure?
GovTech extended Singpass passkey sign-in to Android on 9 September, with roughly 800,000 passkeys already registered from the earlier iPhone rollout.
This matters beyond Singapore because Singpass is a national digital identity that a large number of private services depend on. Moving its authentication to passkeys puts a phishing-resistant layer underneath banking, government and commercial logins simultaneously, rather than every service solving it separately.
Passkeys close off credential phishing because there is no shared secret to hand over. What they do not close off is enrolment and recovery, which is exactly where attackers have been moving. If someone can talk a user into registering an additional authenticator, or can socially engineer a recovery flow, the cryptography is not the thing that breaks.
So the interesting part of any passkey rollout is never the sign-in. It is what happens when somebody says they lost their phone.
For people here who have enrolled: how did the recovery setup work, and did you have to keep a weaker fallback method active alongside it? And for anyone building on Singpass, has the passkey move changed anything on your side or is it transparent to relying parties?
The European Commission is preparing an EU Kids Act proposal that would introduce age-tiered access rules for social media, AI chatbots, video-sharing platforms and online games.
The proposal is still subject to change, but the direction is clear: platforms may be expected to verify age, provide stronger parental controls and reduce access to services or features for younger users.
The difficult part is implementation. Proving that someone is above a certain age is different from identifying exactly who they are. A privacy-preserving system could confirm an age threshold without sharing a full identity record, but it still needs to be reliable and resistant to circumvention.
There is also a question of consistency. If each platform uses a different age-assurance method, users may face repeated checks and uneven protection.
Would a common, privacy-preserving age credential be more workable than every platform building its own verification process?
On 8 September, FinCEN, the OCC, the Fed, the FDIC and NCUA issued joint FAQs on treating verifiable digital credentials under the CIP rule at 31 CFR 1020.220.The short version: a state-issued mobile driving licence can qualify as documentary evidence for customer identification.
What it does not do is remove the verification obligation. Accepting the credential is one thing. Checking that it was genuinely issued by the state, that it has not been tampered with, and that the person presenting it is the subject is another. A screenshot of an mDL (Mobile Driver's Licenses) sitting in a wallet app is not a verified credential, and that distinction is going to cause problems for anyone who reads the headline and stops there.
There is also a channel question. In person you get a device-to-device exchange under ISO 18013-5. Online,presentment runs under ISO 18013-7 and the reader side of that is the part most institutions have not built at all.
For anyone at a credit union or community bank: is your CIP procedure actually being updated for this, and who performs the credential verification, you or a vendor? And has anyone established whether your core provider supports the online presentment flow?
Report published 3 September. More than 80% of responding jurisdictions named underground banking and hawala-style systems among their main professional money laundering channels, and one case involving over 500 million euros moved within months.
The part that stood out is the technology shift. Around 70% of respondents reported some degree of digitisation. Coordination over WhatsApp, Telegram and Signal. Mobile wallets and fintech apps on the customer-facing legs. Virtual assets and stablecoins used for settlement between operators. In some cases purpose-built applications.
That changes the detection problem. Classic hawala left almost no formal footprint, which made it hard to see but also fairly self-contained. The version FATF describes touches regulated rails at the edges: virtual IBANs, prepaid cards, PSP accounts, exchange deposits. Those are places where somebody has an actual monitoring obligation.
FATF also flags the inclusion tension, since these networks serve genuine remittance demand in corridors where formal banking is expensive or missing.
For anyone in transaction monitoring or VASP compliance: are you seeing settlement patterns that look like this? And is anybody tuning specifically for operator-to-operator settlement rather than the customer-facing transfers, which is where most rule sets seem to sit?
OFSI's penalty notice (fine imposed 11 August, notice out early September). The London branch processed 970 payments worth about £19.7 million in breach of the Russia sanctions, mostly across February to November 2022.
The bit worth dwelling on is the Sovcomflot failure. The screening software didn't alert on PAO Sovcomflot because it didn't recognise "PAO", the Russian public joint stock company prefix, and treated "PAO Sovcomflot" as materially different from "Sovcomflot". So the state shipping group sailed straight through. That one gap accounted for a big chunk of it; dozens of accounts and a few hundred transactions. OFSI also points to a backlog in alert reviews, manual steps and human error, all made worse by the flood of designations right after the invasion.
None of that is exotic. It's name matching that doesn't account for local legal entity forms, plus a queue growing faster than the team could clear it.
Which makes me wonder how many screening configs still carry the same gap elsewhere. OOO, ZAO and AO in Russian names. Sdn Bhd, PT, KK, the various GmbH forms. Transliteration only makes it worse.
Two questions for anyone doing this: has your team actually tested its matching logic against local entity suffixes, not just person names? And how are you handling alert backlogs during a designation wave, given the freeze obligation doesn't pause while the queue clears?
On 2 September, FinCEN and the four banking agencies put out a joint statement on what a bank can actually say to a customer when fraud is suspected. It changes no law and adds no new expectations, and they say so at the top. It exists because a lot of people had been reading the rules wrong.
The misreading is that SAR confidentiality means saying nothing at all. It never did. You have always been able to tell someone a transaction looks fraudulent, ask where the money came from, or say an account is closing because of suspected fraud. What you cannot do is confirm a report exists or was filed. The facts underneath are fine. The report itself is not.
The statement even lists examples, including telling a customer a deposit was rejected because a check looked altered, and warning people about money mule schemes.
What stands out is how much practice got built on the wrong reading. Frontline staff ended up with scripts that say almost nothing, because nobody wanted a tipping off finding. Customers get closed out with no explanation, they complain, and that eventually draws a different kind of regulatory attention.
So there is room to say more now, though how much more is still a judgement call.
For anyone doing this day to day, has your institution actually rewritten its customer scripts since the statement, or is legal still holding the old position?
Joint statement came out on 2 September from FinCEN, the Fed, FDIC, OCC and NCUA. Nothing in it is new law, and they say as much up front; no new supervisory expectations. It exists to kill a misreading.
The misreading : that SAR confidentiality means you can't say anything to a customer about suspicious activity. It doesn't. You've always been able to tell someone a transaction looks fraudulent, or that you're closing their account. The line you can't cross is confirming a SAR exists or was filed. Underlying facts, fine. The SAR itself, off limits.
The interesting part is how much operational behaviour got built on that misreading. Plenty of institutions ended up with scripts where frontline staff say almost nothing, because nobody wanted to risk a tipping-off finding. Customers get closed out with no explanation, which drives complaints and, eventually, a different kind of regulatory attention.
So there is now room to say more, but no bright line on how much more is safe.
For people doing this day to day: has your institution actually rewritten customer communication scripts since the statement, or is legal still holding the old position? And where are you drawing the line between explaining a fraud concern and hinting that something was filed?
KYB and individual KYC get treated as the same problem. They age completely differently.
A person's identity doesn't change very often. Businesses do. Directors resign, ownership changes, funding rounds happen, and beneficial owners can cross reporting thresholds long after onboarding. The file you verified a few months ago may no longer reflect reality.
Re-verifying every business on a fixed schedule doesn't seem like the best answer either. It's time-consuming for compliance teams and frustrating for customers, especially when nothing has actually changed.
I've seen a few approaches:
For those working with KYB day to day:
It feels like the real challenge isn't onboarding a business, it's keeping that picture accurate as the business evolves.
Liveness checks are good at detecting things like a photo or replayed video being presented to the camera. But there's a different problem when the attacker bypasses the camera and feeds manipulated video directly into the application.
How are security and identity teams handling this in practice? When evaluating verification systems, dos injection detection get tested alongside liveness/Presentation Attack Detection (PAD), or does the assessment usually stop at liveness?
Would be useful to hear how different teams approach this.
A liveness check confirms a real person is present rather than a photo held to the lens. None of that helps when the attacker skips the camera and pipes video straight into the app, because the check then validates a stream that was fabricated before anything ran.
For anyone who has sat through identity verification vendor evaluations, does injection detection come up at all, or is it still liveness certifications and nothing past it?
People argue endlessly about whether checking someone at signup is still a real control. The rules have quietly answered part of it.
From July 2027, AMLR doesn't just ask whether you verified someone. It asks whether their information is current. So an old file nobody has touched isn't a defence.
Read strictly, that could mean bringing every existing customer up to the new standards by that date. Which nobody could do. The regulators accepted that, and the draft standards say you work through your risk instead, higher risk customer first.
So the answer is somewhere in the middle. The signup check still counts. It just doesn't stay true on its own.
The bit nobody has defined is what "by risk" actually means in practice. How out of date is too out of date? That's your policy and your problem, until a supervisor disagrees with it.
Has anyone set their thresholds for 2027 yet? Curious what people picked.
There is a queue behind that, and it is bigger than most people would guess.
Every Monday somewhere, an analyst opens a review list with a few hundred cases waiting. A customer changed address. A company director resigned. A passport expired and got renewed. Someone opened a savings account next to the current account they already had.
She works through them and closes nearly all of them with no action, because there was nothing there in the first place. Next Monday the list has filled up again.
The serious stuff works as it should. A sanctions match, adverse media, transaction that look wrong for that customer, those get caught and nobody would argue otherwise. It is the ordinary life admin that buries the team.
Two questions keep getting treated as one. Whether something changed, and whether the change actually matters. Moving to the next street is not the same as moving to another country, and plenty of systems cannot tell those apart, so they raise both and leave a person to decide.
Then when something does it matter, it is usually only the changed detail that needs another look. A lot of setups rerun the whole customer from the beginning instead, which is where the hours disappear.
Two questions for anyone who has worked on either side of this. If you have been asked to re-verify for something small, what did the bank actually ask you for? And if you work in one, does anyone ever measure how many of those reviews close with nothing found?
Monday morning. An analyst opens the review queue and there are 400 cases in it.
She works through them. A customer moved house. A director resigned. A passport expired and was replaced. Someone opened a savings account along their current one. By lunchtime she closed most of them with no action, because there was never anything there.
Next Monday, the queue is full again.
This is the bit of continuous monitoring nobody really talks about. The dramatic triggers work fine. A sanctions hit, adverse media, money moving in a way that makes no sense for that customer, all of that gets caught and everyone agrees it should.
It's the small stuff that eats the team alive.
Two things seem to be getting mixed up.
Sort those two out and a lot of that Monday queue quietly disappears, without anyone being less careful about anything.
Or that's the theory. Where does it fall apart in practice? Everyone has a rule that read perfectly well on paper and became a nightmare the week it went live.
Under AMLA's draft RTS on customer due diligence, an obliged entity onboarding remotely must record why neither face to face verification nor an eIDAS compliant method was available or could reasonably be expected.
The interesting part is the second limb. "Reasonably expected" is not defined, and its scope depends entirely on facts outside the text. Today, with wallet availability near zero across most member states, almost any firm can satisfy it. Once every member state has issued a wallet and regulated relying parties are obliged to accept them, the same wording covers far less ground.
There's also a structural point. During consultation, firms argued for broader flexibility to use non-eIDAS methods. The response was that Article 22(6)(b) AMLR refers to eIDAS specifically, so widening the exception would require amending the regulation itself rather than the technical standard. The route is difficult to expand an straightforward to narrow through supervisory interpretation.
Which raises a question about how much practical scope should be left to a term whose meaning shifts with adoption rates rather than with legislative intent. Is that acceptance flexibility, or a drafting problem that will surface in 2028?
Two things are landing close together. Every member state has to offer a digital identity wallet by the end of 2026, and AMLR applies from July 2027.
The wallet's whole design is selective disclosure. Prove one attribute, share nothing else. Prove you're over 18 without handling over a date of birth.
AML obligations run the other way. Firms have to collect specified identity data, keep it current, and retain records for years.
So when a customer onboards with a wallet, what does the firm actually end up holding? If it receives only the attributes it strictly needs, does that satisfy record-keeping? If it asks for the full set anyway, has the wallet's data minimization just been routed around by regulation?
Curious whether anyone has seen this addressed directly, or whether it's still an open question between the two frameworks.