Switching Tracks: How Social Engineers Move Bank Employees Off Guarded Channels
Financial firms verify requests on corporate channels. Callers move employees to personal ones.
Without planning for fallbacks and the limits of employee abilities, organizations leave themselves open to simple, effective social engineering like vishing.
As far as social engineering is concerned, financial firms are ideal targets. Behind their physical and digital walls, their assets are concentrated and liquid.
In late October, the Canadian Centre for Cyber Security warned of an ongoing voice phishing campaign targeting financial and legal organizations. The alert follows similar attacks against major hedge funds, including Citadel and Two Sigma, and several private equity firms earlier this year. Apollo Global Management also disclosed unauthorized access to its cloud platforms through social engineering. Separately, South Korean authorities confirmed data breaches at 16 financial firms and warned that the stolen information could be used in phishing and loan scams.
These campaigns reflect a recurring pattern. With subtle nudges, social engineers exploit how financial institutions do business, persuading employees to bypass established verification procedures through familiar, less-monitored channels.
How attackers use personal technology to access corporate assets
Organizations have two kinds of channels. The corporate track has formal steps, infrastructure, and roles. In the formal channel, a request becomes a ticket, it is logged, and specialists complete it. The firm can keep a record of the interaction. Each action has a specific requirement that can be communicated, checked, and verified.
Figure 1. An attack may involve employees switching tracks, from steps that formal infrastructure monitors and controls to informal requests the firm may not observe. The corporate track has four formal steps. The unmanaged track relies on recognition.
The unmanaged track uses informal requests, consumer technologies, and intuition. When internet connectivity goes down or a corporate system fails, a personal phone can be a critical fallback. The employee recognizes the caller's claimed role and the requested action, even if the caller is unfamiliar. The firm may not observe the call, and formal verification may not occur. The employee relies on their own judgment about the caller and the request.
Recent attacks demonstrate this clearly. Callers phoned employees on personal phones and posed as IT help desk staff. They cited mandatory, urgent security migrations. Victims opened spoofed login portals that captured credentials and MFA tokens. In some cases, callers spoofed the real help desk number. The attackers also used compromised mailboxes to reset passwords and delete confirmation messages. That last step can conceal evidence that might reveal the intrusion.
This has been observed across the financial sector. Callers and messages impersonate IT help desks and send links to personal phones. Attackers then add an authentication method they control.
Why corporate rules break down on personal calls
Regulation is impersonal. It binds the firm and sets dates. NYDFS Part 500 required MFA expansion by November 1, 2025. Firms notify staff and run migrations before a date like that. Employees learn what a mandated change looks like. This also gives attackers open-source intelligence (OSINT), creating an asymmetric advantage.
Rules are published. A caller can learn which changes are due and when. The pretext takes the form of a rule: a requirement, a deadline, and a required action. The call gives that rule to one employee. Legitimate passkey announcements can serve as social proof for fake requests.
Each genuine change can raise the employee's expectation that the next request is genuine. If an employee completes multiple legitimate changes, they may expect more. Expectations, costs, and how well a request's features separate real from false influence the decision to perceive a request as a threat. Caller ID, tone, and link domains can be copied. When a deadline is made public, it can be copied too.
Table 1. These examples illustrate how attackers use personal communication channels and familiar IT procedures to impersonate trusted personnel. Such interactions may leave limited evidence of the initial contact, making attempts more difficult to investigate.
Financial operations are the prototypes for social engineering
Unfamiliarity is unavoidable in large sectors such as banking. Firms serve clients, counterparties, and contractors that most employees do not meet in person. Authority provides a basis for quick decisions. Urgency is currency, with real financial losses and gains at stake in each transaction. Settlement cutoffs and margin calls impose deadlines.
These conditions create opportunities for social engineering. They also create a need for balance. Processes must keep transactions secure and compliant with industry standards. They must also work quickly enough to meet settlement cutoffs.
An effective attacker's script follows the familiar form of such procedures. It gives a reason, requests an action, and sets a deadline. This doesn't need to be explicit. The pressure can feel natural. As losses loom large, time pressure can increase susceptibility to fraud framed as loss avoidance. The conditions are set for the attacker to request or demand that an employee skip a step.
Data exposed in other attacks gives callers details to make these requests more convincing. A contractor's server that stores Daiwa Securities inquiries was accessed without authorization on October 2 and 3, potentially exposing about 220,000 records.
How organizations can control channel switching
Security only succeeds when employees are empowered to act, aware of the appropriate steps, and free to refuse a request without penalty.
Mistakes and limitations are inescapable features of any system. Fallbacks are necessary to navigate unforeseen circumstances of business. Some regulation requires them. For instance, FINRA Rule 4370 requires broker-dealers to plan alternate communications between the firm and its employees for significant business disruptions. Organizations need to accommodate this reality and proceduralize these practices. If fallbacks are not given, employees will develop their own workarounds. Attackers can exploit them.
There is no limit to the workarounds employees can find. Firms must define the fallbacks they permit, the practices they refuse, and the limits of each.
Channel switching must be recognized as a critical decision point. Technical and policy controls must be developed to support it. If organizations do not recognize the need for fallback pathways, the limitations of policies, and employee reliance on sensemaking processes, attackers will exploit these realities.
What is feature engineering
In practice, feature engineering is both science and a bit of witchcraft. It often involves both iteration and experimentation to uncover hidden patterns and relationships within the data. For instance, a data scientist might transform raw sales data into features such as average purchase value, purchase frequency, or customer lifetime value, which can significantly boost the performance of a churn prediction model. By thoughtfully engineering features, practitioners can provide machine learning models with the most informative inputs, ultimately leading to better accuracy and more robust predictions.
What’s more?
- Incorporate more and more data sources
- Feature engineering platform
What is data engineering
As we mentioned above, feature engineering is certainly a subset of data engineering. It involves the ingestion of data from a source, applying a series of transformations, and making the final result available to be queried by a model for training purposes. You can construct feature engineering pipelines to resemble data engineering pipelines, having schedules, specific source and sink destinations, and availability for querying. However, this configuration would only really apply once you have surpassed the experimentation stage and determined a need for a consistent flow of new feature data.
What is feature engineering
1. Functions
Functionally, there is nothing to differentiate data vs features - data points (link). Where feature engineering and data engineering really differ is in the objectives and motivations for constructing the pipelines. In general, data engineering serves a broader, more unified purpose than feature engineering. Data engineering platforms are constructed to be flexible and universal, ingesting various types and sources of data into a unified storage location where any number of transformations and use cases can be applied. The intent of a well constructed fact table or gold layer in a data lake is to provide a single source of truth that answers many different questions, produces many reports, and can be consumed by many downstream customers.
2. Practise
And in practice, an organization’s data engineering team will be responsible for the curation and maintenance of all data pipelines, not just those that relate to machine learning. These pipelines may power BI dashboards used by C-Suite, auditing reports that feed payroll, or event logs that show a user’s history of actions within the application.
Feature engineering, on the other hand, serves a specific purpose, finding the tailored inputs and columns that will generate the best predictive results for a machine learning model. Data scientists and machine learning engineers are not tasked with developing a universal data model that will ingest all data points throughout an organization, they just need to select, curate, and clean the data needed to power their models.
3. Machine learning
Now, as machine learning teams grow and begin to incorporate more and more data sources into their models, their feature engineering platform may start to resemble a larger data engineering platform in the tools and methodologies they employ. But, the intent is not to establish flexible data models that can be used throughout the organization - it is simply to power their machine learning models.
