Multiple Google Cloud services went offline in the London region this morning, according to Google’s status page, and the disruption didn’t stay contained to infrastructure dashboards.
— International Cyber Digest (@IntCyberDigest) October 20, 2026
BREAKING: Revolut's app and cards have stopped working across Europe.
Google Cloud's London region is affected by network failures. Revolut, and many other services, runs on Google Cloud.
Revolut says money and data are safe but has not named a cause. pic.twitter.com/kyxOMlVaak
British digital bank Revolut reported a widespread service outage at roughly the same time, and a person familiar with the matter told Reuters the two events were directly connected.
“Multiple Google Cloud services experienced disruptions in the company’s London region on Tuesday, according to its service status page, while British digital bank Revolut also reported a service outage.” Reuters states, “A person familiar with the matter told Reuters that Revolut’s service outage was related to the Google Cloud service disruption.”
The outage affected Google’s europe-west2 data center, its main facility in London. Google’s engineering team said they were investigating the problem. Alphabet did not immediately respond to Reuters’ request for more information. This is common during an ongoing incident, but it leaves customers unsure when their cards will work again.
Revolut’s own status page showed most services as unavailable or partially unavailable, including card payments and ATM withdrawals. For a bank that exists entirely as an app with no physical branches to fall back on, that’s not a minor inconvenience.
“We are currently experiencing a service disruption affecting multiple services. We can confirm that all our customers’ money and data are safe. We’ve been working to fix the issue since it was identified this morning and apologise to anyone affected and for any inconvenience.” the financial company wrote on X.
We are currently experiencing a service disruption affecting multiple services. We can confirm that all our customers’ money and data are safe. We’ve been working to fix the issue since it was identified this morning and apologise to anyone affected and for any inconvenience…
— Revolut (@Revolut) October 20, 2026
That last sentence is the right thing to say, and it’s also exactly what every bank says during an outage regardless of whether the underlying cause is confirmed. Money and data being safe is a different question from whether you can pay for your coffee.
ING Germany also reported problems on Tuesday. Customers had trouble logging into online banking and the mobile app because of a technical issue. Reuters did not link these problems to the Google Cloud outage, and ING has not explained the cause. Two major financial services companies experiencing problems on the same morning could be a coincidence. However, it also raises questions about how much European banks depend on a small number of cloud providers.
Google Cloud’s europe-west2 region in London supports many UK and European fintech services. Revolut alone serves tens of millions of customers across Europe. When a major data center goes down, the impact can quickly reach customers, preventing them from paying or accessing banking services before the cause is fully understood.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Revolut)
ThreatFabric researchers detailed a new Android banking trojan called Hirudo that takes a genuinely different approach to defeating banking security. Instead of throwing a fake login screen over the real app, it uninstalls the real app and puts a modified copy in its place.
“What sets it apart is the lengths its operators go to once a bank is in their sights: rather than overlaying a fake screen on top of the genuine banking app, Hirudo attempts to replace the banking app itself with a modified copy that quietly disables the bank’s own security checks from the inside.” reads the analysis published by ThreatFabric.
Eight Indonesian banking apps from seven banks already have specially designed replacements ready. The malware’s credential-stealing code also targets users in Indonesia, China, India, Mexico, Morocco, and Thailand.
Hirudo is delivered as a second app hidden inside a convincing dropper. The dropper looks like a legitimate shopping app, short drama platform, or adult video service. It loads real content through a WebView to make the app look genuine. If it detects a banking app on the device and finds that Hirudo is not yet installed, it displays a fake in-app update prompt.
One dropper analysed by researchers goes a step further. During installation, it creates a deliberately broken VPN connection that cuts off the device’s internet access while Hirudo is installed. This does not fully bypass Google Play Protect, but ThreatFabric believes the technique is designed to weaken online reputation checks and code analysis while the malicious APK is being installed. Hirudo is then installed as a separate app from the dropper. Before it can carry out its malicious activities, it must obtain its own Accessibility and notification permissions.
When the payload detects a target banking app, it checks the app’s signing certificate against a stored reference, then shows a fake update prompt and immediately opens Android’s uninstaller without waiting for the user to tap confirm. It downloads the patched replacement in parallel.
“Hirudo keeps a registry of 42 financial apps, but only eight Indonesian apps, across seven banks, have dedicated replacement downloads. For these, the RAT detects the installed banking app through Accessibility, checks its signing certificate against a stored reference, then shows a fake “update” prompt.” reads the analysis. “It opens Android’s uninstaller for the genuine app without waiting for the user to tap, and downloads the bank-specific replacement in parallel.”
The replacement keeps the original package name and version number, but it’s signed with a public test key rather than the bank’s real certificate. Android won’t install it as an update over a properly signed app, which is why the original has to go first. That requirement is a real constraint: the victim can interrupt it. But if they don’t, what follows is clever enough to matter.
The bank’s original code remains almost unchanged. Only one line is added to the app’s Application class. This line loads a built-in hooking engine when the app starts. The engine uses two open-source frameworks: YAHFA to modify Java methods and Dobby to modify native functions. It activates only when it finds a trigger file created by the RAT on the device. Without this file, the modified banking app appears harmless.
Once activated, the engine runs inside the banking app and controls how it responds to security checks. If the app asks for its signing certificate, the engine returns the genuine one. If it checks which accessibility services are enabled, the engine returns an empty list. It also removes the flag that blocks screenshots, allowing the attacker to view and record the banking screen remotely.
Play Integrity checks are sent over plain HTTP to a server controlled by the operator, which returns an acceptable result. Researchers highlight two important points. First, the keybox used for attestation has been leaked publicly, and at least two of its certificates are already on Google’s revocation list. Second, a valid Play Integrity response does not prove that the app has not been tampered with. In this case, the response was relayed through the operator’s server rather than generated through a genuine integrity check.
The lures don’t spread through side-loaded APKs from shady forums. They’re served from Amazon CloudFront, tied to campaign tracking through OpenInstall attribution, and linked to Meta Pixel IDs connecting specific branding to specific campaign groups. Some download routes were still live through late September and into October 2026. The operator APK-processing panel, which rebuilds dropper and payload APKs into finished lures and patched banking apps, was reachable without authentication, with cloud storage buckets and credentials left exposed, a significant operational security failure that helped ThreatFabric map the operation.
Records from August 2026 included thousands of credential entries split across campaign groups, device records, lock-screen history, and financial profiles with monthly income and risk score fields. Operators annotated records they considered “phished,” which signals a workflow built to convert stolen data into actual fraud rather than just collect it.
ThreatFabric’s conclusion on the defensive side is worth reading directly: “once an app can be replaced, its locally produced signals — signature, accessibility list, integrity verdict — must be treated as attacker-influenced and verified server-side.” A valid Play Integrity verdict from a relayed request is not a green light. A clean accessibility list from a patched app is not evidence there’s no controlling service running. The signals the app produces locally are no longer trustworthy, and any bank relying on them as blockers rather than inputs to server-side risk scoring is running on assumptions this trojan was designed to exploit.
“Hirudo marks a deliberate escalation in how Android bankers approach hardened applications. By moving its tampering inside the target app, the operation shifts the contest from the device to the application’s own integrity checks, and from a bespoke patch to a reusable engine that can be retargeted at other apps and regions.” concludes the report. “The defensive conclusion is consistent across every capability we examined: signals produced locally by an app that may have been replaced cannot be trusted on their own.”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Android malware)
Hana Financial’s new headquarters runs private 5G across 16 floors, giving roughly 3,000 employees secure wireless access to internal systems.
The post Private 5G Moves Into Banking at Hana Financial’s 16-Floor Headquarters appeared first on TechRepublic.
What Happened
Recent operational crackdowns by UK Regional Organised Crime Units (ROCUs) showcase the nationwide scale of these networks:
Analyst Comment
Courier fraud is effectively a hybrid cyber-physical social engineering campaign. While the final phase relies on a physical courier arriving at a victim’s doorstep, the initial approach relies heavily on psychological manipulation and email, message, or phone call-based deception.
This type of fraud is notable as it follows a structured cybercriminal playbook that bypasses detection systems and takes advantage of the vulnerable in society. The victim is instructed to bypass normal banking security controls by withdrawing cash, disclosing sensitive credentials (like PINs), or purchasing high-value physical commodities like gold or luxury jewellery. This makes it difficult to proactively detect and prevent.
The other concerning factor is the couriers themselves. According to reports, they can be an unwitting third-party courier service that is paid to go to the victim's home to collect the assets. Online services enable cybercriminals to organise these pickups remotely, lowering their risk of being caught.
The £21 million sizeable loss metric from 2025 shows how profitable this low-tech, high manipulation vector remains. The recent shift to targeting gold and luxury jewellery is a deliberate evasion tactic against traditional anti-money laundering (AML) and banking fraud detection algorithms. While banks have grown adept at flagging unusual rapid bank transfers, they cannot easily stop an account holder from physically withdrawing funds or using a card over several days at different brick-and-mortar luxury retailers. This tactic serves as a highly liquid physical laundering pipeline for these syndicates that remains a challenge to prevent.
Defensive Takeaways
Relevant Sources
Business application development is entering a new operating model. The traditional approach of gathering requirements, designing screens, writing services, integrating systems, testing, fixing defects and preparing release documentation still exists, but it is no longer sufficient for enterprises that need speed, traceability, resilience and regulatory confidence at the same time. Hyperautomation brings a broader discipline to this challenge. It combines workflow orchestration, intelligent document processing, robotic automation, API-led integration, process mining, test automation, observability and artificial intelligence into a connected delivery fabric. With embedded Generative AI, this fabric becomes more adaptive because applications can interpret natural language, summarize complex data, generate explanations, detect exceptions and support decision workflows rather than merely execute predefined rules.
In banking, this shift is especially meaningful. Banks operate across dense application landscapes: trade reporting platforms, wealth management portals, core banking systems, investment banking applications, digital compliance engines, reconciliation utilities, operational dashboards, audit repositories and daily, weekly and monthly reporting platforms. Each of these areas has its own data models, control points, integration patterns, validation rules, exception paths and regulatory obligations. Hyperautomation does not replace engineering discipline; it strengthens it by making business intent, technical execution, control evidence and continuous improvement part of the same lifecycle.
Automation usually addresses a specific task: moving data from one system to another, generating a report, running a batch job or validating a transaction against a rule. Hyperautomation goes further. It looks at the complete business outcome and asks how the entire chain can be streamlined, governed, observed and improved. For example, a trade reporting process may begin with transaction capture, enrich the trade with reference data, validate regulatory fields, identify breaks, generate a submission file, transmit it to a regulator or trade repository, monitor acknowledgements and preserve audit evidence. A narrow automation script may accelerate one step, but a hyperautomated design coordinates the complete flow, including exception handling and evidence generation.
Magesh Kasthuri
Figure: Automation vs. hyperautomation
Embedded Generative AI adds a new layer of intelligence. Instead of forcing every user interaction into rigid screens and codes, business applications can accept natural language prompts, interpret document content, summarize cases, generate draft responses, explain anomalies, produce test scenarios and create release notes. In a banking environment, this intelligence must be carefully bounded. Every AI-assisted action should be traceable, explainable, reviewable and aligned with data privacy, model risk, information security and regulatory expectations. The goal is not uncontrolled autonomy; the goal is governed acceleration.
A modern banking application is rarely a single monolithic system. It is a composition of business capabilities, integration services, workflow engines, data pipelines, user experience layers, analytics models, control dashboards and audit stores. Hyperautomation can accelerate the development and integration of these components by turning repetitive engineering work into reusable patterns and by embedding intelligence directly into business processes.
Embedding Generative AI into business applications should be treated as an architectural capability, not as a decorative chatbot. A banking application may use AI for search, summarization, reasoning support, content generation, code generation, policy interpretation or anomaly explanation. Each use case requires clear boundaries. The application must know which data the model can access, which actions require approval, what evidence must be captured and where deterministic controls must override probabilistic suggestions.
For example, in trade reporting, an embedded AI assistant can explain why a transaction failed validation and suggest likely fields to review. However, the final correction should pass through rule-based validations, maker-checker approval and audit logging. In wealth management, AI may draft a client review note based on portfolio movements and risk profile, but the advisor must verify suitability, disclosures and final communication. In reconciliation, AI can propose likely matches or categorize break reasons, while the system preserves the original data, confidence score, reviewer action and final resolution path.
The Product Development Lifecycle can itself become hyperautomated. Instead of treating ideation, analysis, design, development, testing, security review, release and operations as disconnected phases, enterprises can create an AI-assisted delivery loop where every stage produces structured artifacts that the next stage can consume. Platforms such as GitHub Copilot, Claude Code or Claude Cowork-style agentic development environments and OpenAI Codex can support this movement by helping teams reason over requirements, generate code, create tests, review changes, modernize legacy modules and produce documentation. Their value increases when they are connected to repositories, issue trackers, design documents, build pipelines, test suites, security scanners, observability data and enterprise knowledge bases.
| PDLC Stage | Hyperautomation Opportunity | AI-Assisted Outcome |
| Business discovery | Process mining, domain interviews, regulatory mapping, backlog creation | Structured epics, user stories, acceptance criteria, process maps and control requirements |
| Architecture and design | Reference architectures, API contracts, data models, event flows, security patterns | Architecture options, integration blueprints, threat-model prompts and design decision records |
| Development | Code generation, service scaffolding, UI component creation, data pipeline templates | Review-ready code increments, reusable components, migration utilities and integration adapters |
| Testing | Unit, integration, regression, performance, compliance and synthetic data testing | Generated test cases, defect reproduction steps, test automation scripts and coverage summaries |
| Security and compliance review | Static analysis, dependency checks, policy validation, evidence capture | Risk explanations, remediation suggestions, control traceability and approval evidence |
| Release and deployment | CI/CD orchestration, environment promotion, release notes, rollback preparation | Automated deployment packs, release summaries, operational checklists and change records |
| Operations and feedback | Observability, incident analysis, user feedback mining, backlog refinement | Incident summaries, root-cause hypotheses, improvement stories and reliability recommendations |
GitHub Copilot is useful where developers need assistance inside the engineering flow: explaining code, generating functions, proposing tests, reviewing pull requests and helping teams move from issue to implementation. In a banking PDLC, it can accelerate microservice creation, API integration, batch processing logic, reconciliation rules, regulatory validation routines and UI workflows. When used with repository context and proper review discipline, it can reduce the time developers spend on repetitive coding while preserving human accountability for design and correctness.
Claude Cowork or Claude Code-style agentic environments are valuable for multi-file reasoning, refactoring, debugging and documentation-heavy engineering work. Banking applications often contain deep domain logic scattered across services, configuration files, stored procedures, integration scripts and test suites. An agentic coding assistant that can understand a wider codebase context can help engineers analyze dependencies, prepare modernization plans, update multiple files coherently and draft explanations for reviewers. This is particularly useful in core banking modernization, trade reporting rule updates and compliance workflow refactoring.
OpenAI Codex can support issue-to-pull-request workflows, test generation, code review, bug reproduction, migration activities and broader software engineering tasks across the lifecycle. In a hyperautomated PDLC, Codex-like agents can be assigned well-scoped work items, asked to inspect failing tests, propose fixes, create regression coverage and summarize the change for human reviewers. The important design principle is to keep agents inside controlled boundaries: clear prompts, repository permissions, test gates, approval workflows and traceable outputs.
A practical architecture begins with business capability decomposition. Each banking domain should be expressed as a set of bounded capabilities such as customer onboarding, account maintenance, trade enrichment, exception management, portfolio review, control attestation, report generation and audit retrieval. These capabilities should be exposed through APIs, events, workflow tasks, data products and user interfaces. Hyperautomation then connects these capabilities using orchestration engines, event streams, rules engines, AI services, RPA connectors where legacy integration is unavoidable and observability layers that capture business and technical telemetry.
The embedded AI layer should sit behind a secure application service boundary. It should use retrieval-augmented generation where approved policies, product rules, application documentation and regulatory mappings are retrieved from trusted sources. It should avoid uncontrolled exposure of sensitive customer information. Prompt templates, response validation, redaction, grounding checks, model monitoring and human-in-the-loop approval should be part of the production design. In banking, the most successful AI pattern is often not full automation but assisted decisioning with strong controls.
Consider a reconciliation application that compares ledger balances, payment files, trade settlement records and external statements. In a conventional model, operations teams spend significant time downloading files, running macros, investigating mismatches, documenting break reasons and preparing status reports. In a hyperautomated model, data ingestion is scheduled and monitored, schema checks run automatically, matching engines classify obvious matches, AI assists with ambiguous narratives, exceptions are routed through workflow queues and dashboards update in near real time. At the end of the day, the system can generate a draft operations report explaining unresolved breaks, aging trends, risk exposure and pending approvals.
The same pattern can extend to daily, weekly and monthly reporting. Data quality rules validate inputs, report templates are populated automatically, AI generates narrative commentary on variances, reviewers approve or amend explanations and the final report is archived with lineage and approvals. Audit teams can later retrieve not only the report but also the source extracts, transformation logs, exception history, reviewer decisions and AI-generated drafts. This creates a richer control environment than manual reporting because evidence is captured by design rather than reconstructed later.
Hyperautomation in banking must be designed with governance from the beginning. The development team should define which activities can be automated, which can be AI-assisted and which must remain under human approval. Source code generated by AI must pass normal engineering controls, including peer review, static analysis, dependency scanning, secure coding checks, test execution and production readiness review. Business outputs generated by AI, such as compliance narratives or client-facing explanations, should be reviewed where regulatory or reputational risk is material.
Data governance is equally important. AI-enabled applications must respect data classification, residency, retention, masking and access policies. The model should not become an uncontrolled channel through which confidential customer, trading or employee information can leak. Every prompt, retrieved source, generated response, user action and final decision may need to be logged depending on the use case. For audit applications, this traceability is not optional; it is the foundation of trust.
A hyperautomated PDLC requires changes in team behavior. Product owners should write requirements in a structured manner so that AI tools can generate better stories, acceptance criteria and test scenarios. Architects should maintain living decision records, reference patterns and integration standards that AI agents can use as context. Developers should learn prompt discipline, context packaging and review techniques. Test engineers should focus on coverage strategy, synthetic data, compliance scenarios and defect prevention rather than only manual execution. Operations teams should feed incident learnings back into the backlog so the system improves continuously.
The role of human experts becomes more important, not less. AI can draft, generate, compare and suggest, but domain judgment remains essential. A trade reporting specialist understands regulatory nuance. A wealth advisor understands client suitability. A core banking architect understands transaction integrity. A compliance officer understands control interpretation. Hyperautomation works best when it amplifies these experts and removes repetitive friction around them.
Hyperautomation in business application development is not simply a faster way to write software. It is a new way to connect business intent, engineering execution, operational control and continuous learning. In banking, where applications must be reliable, explainable, secure and compliant, the combination of embedded Generative AI and disciplined automation can transform how applications are designed, built, integrated, tested, released and operated. Trade reporting, wealth management, core banking, investment banking, compliance, reconciliation, reporting and audit functions can all benefit when AI is embedded responsibly and automation is orchestrated across the complete lifecycle.
Platforms such as GitHub Copilot, Claude Cowork or Claude Code and OpenAI Codex can play an important role in this transformation by accelerating analysis, development, testing, review, modernization and documentation. Their greatest value appears when enterprises treat them not as isolated productivity tools but as part of a governed, AI-native PDLC. The future of banking application development will belong to teams that can combine human expertise, reusable engineering patterns, intelligent automation and strong governance into one coherent delivery model.
This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.
The United States Senate Federal Credit Union (USSFCU) is a nonprofit financial cooperative that provides traditional retail banking services to entities within the US government, such as the Senate and the Supreme Court.At present, the credit union’s headcount stands at nearly 150 people, managing around $1.6 billion in assets.
A few years back, when it started to expand its use of technology, cybersecurity was a key focus area, but the financial institution faced two major challenges in boosting security as it scaled. The USSFCU was carrying significant technical debt, and there were holes in the organization’s defenses.
“We found gaps where we needed more systems, tools, and people, and then there were instances where we had technologies in place that weren’t being used effectively,” says Mark Fournier, CIO at the credit union. “We weren’t buying a bunch of shiny new things without thinking about it. We were actually quite prescriptive every year, performing a number of different exercises to identify our shortcomings and then finding the right solution to fill the gaps. But over time this adds up. It was clear we couldn’t keep hiring more people and bringing in new solutions.”
The USSFCU needed a more efficient way to bring everything together and make its cyber estate easier to manage. For Fournier and his team, vulnerability management was the hardest hill to climb since they have to deal with about 100 new possible breach points every day.
“When we looked at the problem more closely, the impact of these vulnerabilities was far greater than we realized,” he says. “Not only because of the volume but because of a lack of clear understanding around the potential impact of each one across the broader business.”
The USSFCU didn’t lack security tools, however. In fact, it had plenty, from scanners and endpoint tools to asset records, tickets, and internal documentation. But each tool saw only a slice of the environment, so there was little to no context. This made it difficult for the security team to separate real business risk from noise.
So for each new vulnerability, the security team had to run a manual investigation, which could take days. And while doing this, they still had to triage the next wave of findings. The organization, therefore, needed a way to know what mattered, why it mattered, who owned it, and whether taking the time to make a fix actually reduced risk. The USSFCU also required a solution to be deployed entirely in-house, leveraging its internal inferences.
Working with Tonic Security, the organization deployed an exposure management solution that pulls together data from different tools and data sources to create a clear picture of business risk. “One of the key functions of the platform is the ability to ingest anything,” says Fournier. “Breaking down silos between disparate systems is essential to unlock valuable contextual information.”
For the USSFCU, transparency and explainability are critical, he adds. This tool uses an AI data fabric to extract context from structured and unstructured data. This context drives prioritization, ensuring the right owner gets the right evidence, not a vague ticket. And once the work is done, the solution checks whether the exposure was reduced.
Because the AI is grounded in the customer’s own environment, it isn’t just guessing from a generic risk model. It reasons over USSFCU’s assets, owners, services, tickets, controls, and business context. But it isn’t using this data to train external models.
Describing one particular incident, Fournier explains that shortly after the initial deployment, various stakeholders met to assess progress. “We thought we were smart because we found an error with the platform,” he says. “The solution had labelled an asset as internet exposed, which we knew was incorrect.” But after a review and lengthy discussion, they were proven wrong. “Almost immediately, the value of bringing this information together became apparent.”
Before this solution, a high-severity finding could send an analyst on a lengthy scavenger hunt because of data located in so many different places. They’d check the scanner, asset inventory, tickets, and maybe even ask around to find the owner. But now they can find the asset, the owner, the business relevance, the exposure path, and the recommended action in one place. The solution has reduced the time taken to resolve a vulnerability by 75%. And with a clearer idea of what is and isn’t important, and what adds practical value, the number of incidents someone needs to respond to has reduced from about 100 a month to just 10.
Sharing his lessons from the project, Fournier says one needs to keep an open mind because the problem you think you have is often very different from the one you actually have. “This project has also been an eye-opener around how people can collaborate and operate across different areas of the business,” he says. “When I talk to my peers, they regularly highlight the disconnect between different departments and business functions. But with a project like this, when you’re crossing traditional boundaries, you need to have open lines of communication to succeed.”
The transformation of the financial sector is no longer just about offering a mobile app or allowing customers to bank from anywhere. After years of digitizing services, institutions now face the more ambitious challenge of building a more personalized, agile, and intelligent relationship with millions of users who expect immediate answers, simple experiences, and service tailored to specific needs.
The emergence of gen AI has accelerated this evolution. While banks have used AI models for years to automate processes, improve efficiency, and analyze large volumes of data, a new generation of conversational tools opens the door to a much more natural interaction between customers and financial institutions.
Spain’s CaixaBank, for example, has positioned AI as one of the cornerstones of its technological transformation. The bank, which has more than 12 million digital users, believes this change isn’t solely due to tech’s evolution, but also to a shift in user expectations.
“Today’s customer is more digital, autonomous, and also more demanding in their relationship with the bank,” says Mariona Vicens, CaixaBank’s director of digital transformation and advanced analytics. “They not only interact more through digital channels, but also expect simplicity and personalized solutions at any time and from any device.”
Although gen AI has made a big impact, CaixaBank says its commitment to these technologies began much earlier. But it now represents a qualitative leap. “It’s more focused on developing new models based on conversational applications,” she says. “The most visible improvement is that gen AI allows for more natural, contextual, and useful interactions for both employees and customers.”
This evolution is part of CaixaBank’s 2025-2027 Strategic Plan, in which it identifies agility, new services, efficiency, and technological resilience as main and interconnected objectives. For Vicens, agility is particularly key. “It’s what allows us to respond to a customer who increasingly expects immediacy, and it’s also what determines the bank’s ability to adapt in an increasingly dynamic environment.”
The Cosmos Plan, the specific roadmap for processes and technology framed within CaixaBank’s strategic plan, reflects this integrated vision. “It combines investment in technology, automation, and AI to enable a more flexible and efficient organization capable of evolving at the pace set by customers,” she says. “Ultimately, agility is the visible engine of change, but it’s only possible when all elements of the model advance in a coordinated manner.”
AI is certainly at the forefront of how the bank operates. More than 2,000 employees are already using agents to automate tasks, streamline processes, and improve customer service — a number the bank expects to increase before the year’s end. “With this implementation, combined with the application of other models like gen AI integrated into office tools, we expect to scale the gains in productivity and agility,” Vicens says.
While AI opens up new possibilities for transforming customer relationships, it also presents challenges related to regulation, transparency, and trust. For CaixaBank, innovation isn’t just about developing new use cases, but doing so under a governance model that ensures the technology is used responsibly.
With that objective, the bank has defined a specific governance framework for these tools, with a corporate-level AI Office and a policy that anchors principles such as transparency and explainability, data fairness and privacy, robustness and security, and human oversight.
This framework, CaixaBank explains, translates into concrete controls throughout the entire AI lifecycle: prior validation of use cases, structured risk assessment before implementation, corporate inventory of systems, subsequent monitoring, and incident management. However, it’s all based on the clear premise that relevant decisions can’t be entirely delegated to AI, so they must maintain human oversight.
The entry of the EU AI Act has placed financial institutions under evolving regulatory requirements. Far from seeing it as an obstacle, CaixaBank believes this framework fits perfectly with how it’s approached the tech all along. “It fits naturally, because we’re precisely structuring our AI governance model with this framework and other regulatory frameworks as a reference, and we integrate it into the AI lifecycle from the design stage and by default,” says Vicens.
Corporate policy explicitly incorporates the regulations into its global risk management system. In practice, any AI-based application must follow a clearly defined process before being implemented. “This means that any use of AI must be identified, evaluated, and monitored,” she says. “Before developing a use case, its type, value, and feasibility are validated, and then its risks are assessed. And once implemented, its performance is monitored.” Of course, in a financial environment, customer trust remains a most valuable asset.
All this transformation strategy is finding a tangible application in one particular development: a contracting assistant that accompanies the client through digital channels. The system acts as a first point of contact when a user requests information about a product from the CaixaBank website or app. From there, it can answer questions, provide contextual information, guide the conversation, and, when necessary, transfer the interaction to a specialist without the customer having to restart the process.
For the bank, this ability to understand context is a key differentiator. “Unlike a chatbot that answers a collection of FAQs, this agent is a contracting assistant that understands the context of the conversation with the customer, provides support, and can escalate to a human,” she says. For products like pre-approved loans, it can even lead the conversation to the final step before closing.
The bank emphasizes that human intervention remains an essential part of the process. “We see AI as a tool to inform, streamline, and support the customer to enhance their user experience in a way that complements the ongoing support provided by our team of specialized remote banking managers,” Vicens adds. Plus, customers can choose to speak with a human from the outset or at any point during the conversation, and the final contract is always signed with the assistance of a CaixaBank specialist.
Beyond human oversight, the bank has established a framework to ensure the responsible use of AI. “It has defined responsible AI principles that cover the entire lifecycle of developments to ensure fair, transparent, responsible use, aligned with legislation and the group’s values,” she says. “Before deploying any AI solution aimed at customers, compliance with these principles is verified.”
In the specific case of the contracting assistant, data protection is one of the essential elements. The information travels encrypted, and the model isn’t trained with the data sent to the LLM.
Currently, this technology is available in 40 products and manages an average of 6,000 conversations per month — figures that, according to CaixaBank, provide clear metrics of scale and productivity.
The implementation of the onboarding assistant is one example of a much broader strategy in which AI, data, and automation are used to transform the relationship between the bank and its customers. “The key is no longer just being available, but providing real value in every interaction, and strengthening trust through useful experiences tailored to each user,” says Vicens.
RedHook malware uses fake banking and government apps to steal data and control Android phones, with attacks confirmed in Vietnam and Indonesia so far.
The post Fake Bank Apps Let Scammers Control Android Phones in Southeast Asia appeared first on TechRepublic.
Letter from group published by MPs blames 12 March glitch on software update to its mobile banking apps
Lloyds Banking Group exposed the personal data of nearly 500,000 customers in an IT glitch that left people’s payments, account details and national insurance numbers visible to other users, a committee of MPs has revealed.
A letter from Lloyds, published by MPs on the Treasury select committee on Friday, blamed the glitch on a software defect introduced during an IT update to its Lloyds, Halifax and Bank of Scotland mobile banking apps overnight into 12 March.
Continue reading...
© Photograph: David Burton/Alamy
© Photograph: David Burton/Alamy
© Photograph: David Burton/Alamy
Entrar