<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Risk Control on goodinfo.net Daily</title>
    <link>https://goodinfo.net/en/tags/risk-control/</link>
    <description>goodinfo.net daily curated global news: AI, tech, finance, and world affairs.</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <author>goodinfo.net</author>
    
    
    
    <lastBuildDate>Fri, 23 Oct 2026 04:15:00 +0800</lastBuildDate>
    <atom:link href="https://goodinfo.net/en/tags/risk-control/index.xml" rel="self" type="application/rss+xml" />
    
    <item>
      <title>US Banks Block Third-Party AI Agents From Customer Accounts</title>
      <link>https://goodinfo.net/en/posts/ai-tech/us-banks-block-third-party-ai-agents-2026-10-23/</link>
      <pubDate>Fri, 23 Oct 2026 04:15:00 +0800</pubDate>
      <author>goodinfo.net</author>
      <guid>https://goodinfo.net/en/posts/ai-tech/us-banks-block-third-party-ai-agents-2026-10-23/</guid>
      <description>Several US banks have started blocking unvetted third-party AI agents at the account and payment-instruction layer, according to sources cited by Reuters. The common pattern described is that automated instructions not issued by the bank&rsquo;s own application triggered risk flags, and some accounts were refused service. That pushes the agent-permission question out of the application layer and into core financial infrastructure, ahead of any formal rule.</description>
      <content:encoded><![CDATA[<p><strong>[Core Summary]</strong></p>
<p>Several US banks have begun detecting and blocking unvetted third-party AI agents at the account and payment-instruction layer, according to sources cited by Reuters. The common pattern described is that automated instructions which did not originate from the bank&rsquo;s own application triggered risk flags in behaviour monitoring, and some accounts were refused service outright. This moves the agent-permission question out of the application layer and into core financial infrastructure, ahead of any formal rule.</p>
<p><strong>[Event Details]</strong></p>
<ul>
<li><strong>How it surfaced</strong>: According to the reporting, the unusual activity was identified inside the banks&rsquo; own behaviour monitoring rather than through a regulatory notice or an external security disclosure.</li>
<li><strong>Where it was blocked</strong>: The measures sit at the account access and payment-instruction layer, outside the bank&rsquo;s own channels, which amounts to a direct refusal of third-party automated calls.</li>
<li><strong>What triggers it</strong>: The feature sources describe as common is the unauthorised origin of the caller, not the content of the instruction itself, which is part of why this activity went unnoticed for as long as it did.</li>
<li><strong>A parallel case</strong>: In the same window, reporting showed a large retail platform taking the opposite route and opening a shopping-agent interface to external agents. Two institutions, two directions.</li>
<li><strong>What kind of action this is</strong>: These are a bank&rsquo;s own operational risk measures, not a regulatory obligation. The two are legally distinct even when they are hard to tell apart from the customer&rsquo;s side.</li>
</ul>
<p><strong>[Wider Perspective]</strong></p>
<p>Looked at from inside a bank, what is being repriced is not any single feature but the verifiability of an agent&rsquo;s identity. Conventional financial risk control evaluates the account holder: whether the money left the person&rsquo;s own account, whether the device is one they habitually use, whether the pattern matches long-standing behaviour. An agent-driven call introduces a variable the old model cannot attribute, because the instruction originator is not the account owner at all. That is why this activity required banks to adjust their monitoring criteria rather than relying on existing rules to catch it automatically.</p>
<p>What is notable is that the banks chose refusal rather than permission plus limits. The softer approach is easier to build and matches how the payments industry has handled odd transactions for years, because a cap at least bounds the maximum loss. But that logic does not fit agents. Their risk does not live in the size of any single instruction; it lives in the ability to persist across many small, dispersed, individually unremarkable operations. While headroom remains, an agent can operate below every threshold indefinitely, and the account holder may never notice. Blocking outright is therefore an admission that current tooling cannot yet price this class of caller.</p>
<p>There is a second reading worth taking seriously: this may be a policy declaration performed in the language of risk control. Where rules are absent, regulatory arbitrage gets filled in fast. Whichever institution publishes an enforceable standard first effectively draws a temporary baseline. That baseline may never be adopted in rulemaking, and may be so strict it forecloses legitimate uses, but it does shape how developers build in the interim. For product teams this means answering a question that was rarely asked before: not whether they can make the call, but how they will later prove they were authorised to make it.</p>
<p>The episode also exposes a basic gap in the agent ecosystem, namely the absence of an authorisation credential format that multiple parties can accept. Verbal consent and a click-through approval are common today, and neither survives an audit or travels across institutions. A credential that lets a user authorise a specific scope for a specific window is the plausible technical exit. Until one exists, banks and platforms will each improvise their own blocking rules, and the user absorbs the resulting inconsistency from both sides.</p>
<p><strong>[Multiple Perspectives]</strong></p>
<ul>
<li><strong>Sources cited</strong>: The reporting emphasises that detection happened inside bank monitoring systems rather than through a regulatory channel, suggesting exposure preceded public discussion.</li>
<li><strong>The retail platform side</strong>: The institution that opened an agent interface argues that controlled access expands legitimate use, while outright refusal pushes users toward less regulated alternatives.</li>
<li><strong>Risk practitioners</strong>: Practitioners broadly agree that agent calls do not fit the traditional limit-based framework, which is the technical reason for blocking rather than capping.</li>
<li><strong>Compliance observers</strong>: A recurring caution is that operational blocks are a bank&rsquo;s own choice rather than a legal duty, yet customers will struggle to tell the two apart.</li>
</ul>
<p><em>Editor: GoodInfo Global News Team</em></p>
]]></content:encoded>
      <category domain="category">ai-tech</category>
      <category domain="tag">Artificial Intelligence</category><category domain="tag">Fintech</category><category domain="tag">Risk Control</category><category domain="tag">Banking</category><category domain="tag">Agents</category>
    </item>
    
  </channel>
</rss>
