Support Portal

A signal is EFI's way of telling you that something has been published about one of your counterparties that may matter for financial crime compliance. Signals arrive on their own — you don't have to go looking for the news.

This guide explains the whole journey: how coverage is found, how it is read and categorised, how related articles are grouped into a single story, what EFI adds to it, and how the finished signal reaches your queue. Knowing the chain makes it much easier to judge what a signal is telling you — and to spot the few places where your own input changes what EFI finds.

The journey at a glance

Stage 1 — Discovery

Which counterparties are monitored

Monitoring is not automatic for every entity in the platform. A counterparty is monitored once it belongs to a monitored portfolio. If an institution you care about is never producing signals, that is the first thing to check with your account manager — it is far more often a subscription question than a coverage one.

The nightly search

Once each night, EFI searches the previous day's news coverage for every monitored counterparty. Each run looks at the last 24 hours only and works through up to around a thousand results per entity.

This has one consequence worth internalising: adding a counterparty to monitoring does not pull in its history. From the moment it joins, you get everything new. Anything published before that point has to be requested deliberately — see Lookup below.

The names EFI searches under — your biggest lever

The search is built from the institution's name plus every alias recorded against it. A bank known variously as "Banco Nacional", "BN Group" and "BANNAC" will only be found under the names EFI actually holds.

This is the single most effective thing you can do to improve coverage. Open the institution from Counterparties, use Edit institution, and add every trading name, former name, local-language name, and common abbreviation you know. Each one becomes an additional way for EFI to find coverage that night.

Filling in the LEI and BIC when you add an institution helps too — they improve how accurately EFI matches the entity against public registries.

The four ways a signal can start

Lookup — pulling in history

The Lookup control opens a dropdown with two ways to search back in time:

• Quick Options — Last Week, Last Month, or Last Year. These run immediately when clicked.
• Custom Date Range — pick a From and To date, then click Run Lookup.

You'll see a confirmation that the lookup was queued for your chosen dates. Use this when you onboard a counterparty, when you inherit a portfolio, or when an investigation needs the backstory rather than just what broke last night. A lookup searches far more deeply than a nightly run, so give it time to work through.

Scan URL — submitting an article yourself

When a colleague forwards you a story, or your own research turns up something EFI hasn't picked up, use Scan URL. The Add URLs as Signals dialog takes one URL per line, up to 20 at a time, and shows a running count of how many you've entered along with any that aren't valid links. Click Submit URLs.

Each submitted page is fetched, read, and categorised exactly the same way as an article EFI discovered on its own — a manually submitted URL is not treated as second-class evidence. It also passes through the same grouping step, so if the article belongs to a story EFI already knows about, it joins that existing signal rather than creating a duplicate. Your name is recorded against anything that results, so the queue shows where a finding came from.

The dialog confirms your URLs were submitted and mentions being notified when processing completes. Take that as confirmation of receipt only — no notification is sent to you. Come back to the signals list and refresh in a minute or two.

Where to find these two controls. Scan URL and Lookup appear only when you're looking at a single counterparty's signals — from the institution's Signals section, or the signal list opened via Go to signals. They aren't available on My Signals, because both actions have to know which entity they apply to.

Website monitoring

Separately from news coverage, EFI can watch a counterparty's own website and check it daily for changes. When a page changes, the old and new versions are compared and the change is scored for how meaningful it is. Only changes that clear a materiality bar become signals — a reworded footer won't reach you, a quietly removed board member will. The old content, the new content, and the difference between them are all attached as evidence.

Stage 2 — Reading and categorising each article

Every article found is read and assigned exactly one category — the financial crime typology it represents. This is what turns a pile of news into something you can triage.

The categories

Categories are shown throughout the platform as a code and label, for example FRD - Fraud, Scams, Swindles. They fall into natural groups:

Financial crimes

Serious crimes

Other crimes

Cyber and structural

Regulatory and sanctions

Not adverse

What else is captured about each article

Alongside the category, EFI records several attributes that help you judge how much weight to give a finding:

• Involvement — whether your counterparty is the primary subject of the story or a secondary mention. A bank named in passing in a story about someone else is very different from a bank under investigation.
• Role — how the entity features: perpetrator, victim, facilitator, beneficiary, regulator, or observer. A bank that was defrauded and a bank that committed fraud both produce a fraud-category article; the role is what separates them.
• Sentiment — negative, neutral, or positive. Positive matters more than it sounds: charges dropped or an entity cleared is recorded as positive coverage of an adverse topic.
• Paywall — whether the source was behind a paywall when EFI tried to read it.

EFI is deliberately cautious

The categorisation step is built to avoid inventing risk. It doesn't assume guilt beyond what a source actually states, and when the evidence is thin it says so rather than guessing. If an article can't be read at all — a paywall, a dead link — it is recorded as having no adverse finding rather than being categorised on the strength of a headline.

Two categories exist for exactly this purpose. INF means the article is genuinely about your counterparty but isn't adverse — a routine business update or a neutral profile. A third state, used when there simply isn't enough evidence to conclude anything, means no adverse finding was detected at all.

Non-adverse findings still get recorded

Articles that turn out not to be adverse still produce a signal — one that is created already closed. This is deliberate. It gives you a complete audit trail showing that EFI saw a piece of coverage and considered it, rather than silently discarding it. When a regulator asks what you knew and when, that record is the answer.

These auto-closed signals don't consume a case number and don't clutter your working queue. On Signal Cases, the Exclude completed signals filter hides them by default; uncheck it when you need the full picture.

Stage 3 — Filtering out false positives

Before a story reaches you, EFI runs a second, independent check asking a blunt question: is this really about this counterparty, and is it really adverse?

Two things get filtered out:

• A different entity with a similar name. Company names overlap constantly — a story about "Cable One" is not a story about a bank called "ONE". This check catches lexical matches that aren't your counterparty at all.
• The right entity, but nothing adverse. Product launches, sponsorships, marketing campaigns and charitable donations are about your counterparty but carry no compliance significance.

A small number of low-quality outlets are also excluded outright. Articles from them are still recorded for completeness, but never become signals.

This filter is intentionally biased toward keeping things. A missed signal is a far worse outcome than one you dismiss in thirty seconds, so anything genuinely ambiguous is passed through to you rather than filtered away. Lawsuits, settlements, fines, investigations, insider trading, data breaches, labour and safety matters, and cases where your counterparty is only peripherally involved are all explicitly kept. Expect to see findings you'll close as not relevant — that is the system working as intended, not failing.

Stage 4 — Grouping related articles into one story

A significant enforcement action might be covered by thirty outlets in a day. You should review that once, not thirty times.

So EFI groups articles covering the same underlying event into a single topic cluster, and it is the cluster — not the individual article — that becomes your signal. Ten outlets reporting the same fine produce one signal citing ten sources.

What has to match

For two articles to be considered the same story, all three of these must hold:

• Same counterparty. Stories about different entities never merge.
• Same category. A fraud story and a bribery story about the same bank stay as two separate signals, by design. Different typologies mean different investigations.
• Within twelve months of each other. Coverage of a long-running matter stays connected; a new incident years later starts fresh.

Within those bounds, EFI compares the substance of the articles — the organisations and people named, what actually happened and where it stands, monetary amounts, dates, jurisdictions, the sources reporting it, and the wording itself. Where that adds up to the same event, the articles join the same story.

The bar for grouping is set generously. Bringing related coverage together is more valuable than splitting hairs over whether two reports are perfectly identical.

Stories grow over time

A cluster is not frozen when it's created. When new coverage of the same event appears days or weeks later, it joins the existing story. When that happens:

• No new signal is created. The existing one is updated in place, keeping its history, comments and assignment.
• The article count goes up and the new source appears in the signal's article list.
• The summary is updated to reflect genuinely new facts — new amounts, new dates, a change in status. Existing wording is preserved rather than rewritten, so the summary doesn't churn between reviews.
• The title usually stays the same. It changes only when the story has materially moved on — a new development, a fundamental change in scope, or a title that has become misleading. Stability is favoured, so a title you recognise still means the signal you remember.

Merging stories yourself

If you spot signals that clearly describe the same event, select them in the list and use Merge Signals. The articles move into a single story, the summary is rebuilt from the combined set, and the signals that were absorbed close with the reason Merged.

Because EFI keeps categories separate when grouping, merging is how you deliberately override that — for example when a bribery story and a fraud story turn out to be two facets of the same enforcement action. If the signals you selected carry different categories, EFI asks you to Select Category for Merged Signal so you decide which typology the combined case should carry.

Stage 5 — Enrichment

Once a story exists, EFI builds it into something you can actually work from.

The AI-generated summary

Every signal carries a structured summary synthesising all articles in the cluster, not just the first one. It covers:

• Event Overview — what happened, and what led to it
• Parties Involved — institutions and their roles, the regulators and authorities involved, and the key individuals named
• Timeline and Development — when it happened, when it was first reported, and how it has progressed
• Financial and Regulatory Impact — specific amounts, penalties and losses; regulatory actions taken or threatened; market reaction
• Current Status and Resolution — whether the matter is ongoing, under investigation, settled or resolved, and what's expected next
• Sources and Credibility — how consistent the reporting is across sources, how diverse those sources are, any conflicting accounts, and the time span the coverage covers
• Risk Assessment Implications — what this means for the counterparty's risk profile and your compliance obligations

Source ratings

Every article is rated by the standing of its source, which tells you how much weight the underlying reporting carries:

A MLA finding sourced entirely from Tier 3 blogs deserves a different response than the same finding carried by a regulator's own enforcement notice. Tier 1 articles also have their full text retrieved automatically at discovery, so they're readable immediately.

Cached copies of articles

News articles disappear. Links rot, stories get pulled, paywalls harden. EFI stores its own copy of the article text as the signal is created, so the evidence behind a signal survives even when the original doesn't.

Where a cached copy exists, the article entry offers View Cached Version alongside the link to the original. Two views are kept: a clean extracted-text version, and the page as it originally appeared.

What each article shows

Within a signal, every article is listed with its source, tier, publication date, category, involvement, sentiment, a link to the original, and its own short summary. Above ten articles the list collapses into an expandable block so the summary stays readable.

A Topic Information section holds the story's own metadata — when it was first seen, when it was last updated, the total article count, and the primary category.

If you want the analysis refreshed — for instance after an article that was paywalled becomes readable — use Enrich Articles on the signal to re-run it.

Stage 6 — The signal reaches you

The finished story becomes a signal in your queue.

• Its title is the story's topic, written to describe the event rather than parrot one outlet's headline.
• Its status is open if the finding is adverse, or already closed if it isn't.
• Its category is the typology assigned during analysis, which you'll be asked to confirm.
• Its institution links to the counterparty, so the signal appears on that entity's report as well as in your queue.

There is no severity score — and that's deliberate

Signals don't carry a severity rating or a priority level. A single number would flatten exactly the distinctions that matter, and how urgent a finding is depends on your risk appetite and your relationship with the counterparty — not on the news itself.

What you have instead is richer. Triage on the combination of:

A TER finding where your counterparty is the primary perpetrator, reported by six Tier 1 sources, is self-evidently not the same as a REG mention where it appears as a secondary party in a single Tier 3 blog — even though a severity score might well have rated them alike.

Where signals appear

• My Signals — the cross-portfolio queue, which can default to just your own assignments.
• Signal Cases — the full queue for a counterparty, reached from that entity's page.
• Dashboard — open counts, category breakdown, creation trend, and Quick Assignment for signals nobody owns yet.
• The institution report — the Signals section lists findings for that counterparty; Go to signals in the actions dropdown opens the queue filtered to it.
• Entities — the Signals column shows a count per counterparty; click it to jump straight to that queue.
• Signals Report — periodic view of how many signals were created, how fast they were worked, and how accurately they were categorised.

Nothing tells you a signal has arrived

This is worth stating plainly, because it shapes how you need to work. No notification or email is sent when a signal is created. The only signal notifications are when a signal is assigned to you, unassigned from you, or changes status — and those depend on your notification preference in your profile.

New signals appear silently in the queue. Reviewing My Signals or the Dashboard on a regular cadence is how you stay current — not waiting to be told.

Stage 7 — EFI takes a second look

The first pass reads an article's headline and opening text, because that's what a news search returns. That's usually enough to categorise correctly, but not always.

So EFI goes back over open signals, retrieves the full text of each article, and re-runs the analysis on the complete story rather than the summary. Reading the whole article sometimes changes the conclusion: a headline that reads as an accusation turns out to describe a case that was dismissed, or a passing mention turns out to be a substantive finding.

When the fuller reading changes things, the signal is recategorised — or closed, if the whole story turns out not to be adverse — and a note is added to the signal recording what changed and why. You'll see it marked as an agent review, above the summary.

Three safeguards are worth knowing:

• Your decisions are never overwritten. If you have confirmed or changed the category, the signal is left alone entirely.
• It will not close a signal on partial evidence. If any article in the story couldn't be fully retrieved, the signal stays open for a human to judge.
• Any single adverse article keeps the story open. A signal is only reconsidered for closure when every article in it, read in full, turns out to be non-adverse.

Stage 8 — Your review closes the loop

The chain ends with you, and what you do is recorded.

On the signal's own page the platform calls it an alert — so the buttons read Close Alert and the identifier reads Alert ID. It's the same object you selected from the signals list.

Confirming the category

Confirm Category timestamps your agreement with EFI's assessment. If the category is wrong, change it first using the pencil next to Category, then confirm. Changing the category re-categorises every article in the story, not just the signal header.

Until it's confirmed, a warning icon sits next to the category reading "Category must be confirmed before closing".

You can't close a signal on autopilot

EFI deliberately blocks closure until two things are true: the signal is assigned to someone, and its category has been confirmed. Until then the close button stays disabled and the page tells you what's missing — "Before closing, please confirm the category and set the assignee".

This is what makes a closed signal defensible. Every resolved finding has a named owner and a category a human agreed with.

Closing with a reason

When you close a signal you choose why:

Monitoring behaves differently from the rest: it offers a Reopen date, and the signal automatically comes back into your queue on that date. Use it for a story that isn't actionable yet but shouldn't be forgotten — an investigation announced with no outcome, for instance.

Two further reasons appear in the list and filters but are never chosen by hand: Automatically Closed, applied when EFI determined the article wasn't adverse, and Merged, applied to signals absorbed into another story.

What your decisions actually do

Confirming or correcting a category has a concrete effect: the automated re-review will never touch a signal you have judged. Your assessment is final, and stage 7 skips it entirely.

Your decisions also drive the Signals Report, which tracks Category Accuracy — how often EFI's initial assessment matched your final decision — and the True Positive Rate. Those figures are how you evidence to a regulator that your adverse media monitoring is not only running but being reviewed, and how you spot categories where EFI consistently misreads your portfolio.

One honest caveat: your corrections do not retrain the system. They lock in your judgement and they measure accuracy, but the next signal is categorised by the same reasoning as the last one. If you see a category consistently misapplied to your counterparties, raise it — that's a change to be made deliberately, not something the platform learns on its own.

What you actually control

Limits worth knowing

Being clear about what the system does not do is as important as what it does.

• Coverage is news-based. Discovery searches published news coverage. It is not a substitute for sanctions and watchlist screening, which is a separate part of the platform.
• Onboarding does not backfill. A newly monitored counterparty starts producing signals from that night forward. Its history needs a deliberate Lookup.
• There's no progress view. After you submit a Scan URL or run a Lookup, nothing shows you how far along it is. Results simply appear in the signals list — refresh it after a short wait rather than expecting to be told.
• Adverse media monitoring isn't self-service. There's no settings page where you switch it on, choose a frequency, or pick categories. It's configured for your portfolio during onboarding. (The Monitoring Settings page you may have seen configures transaction monitoring rules — a different part of the platform entirely.)
• Analysis is automated and can be wrong. Every signal carries a note reminding you it was automatically generated. Always verify anything material against the original source before you act on it — the links and cached copies are there precisely so you can.
• Aliases are your responsibility. EFI can only search under the names it holds. Coverage gaps most often trace back to a missing alias.

Related guides

• Signal Cases — the day-to-day workflow for filtering, reviewing and closing signals.
• Ticket Detail View — the full detail page, shared with screening and monitoring alerts.
• Signals Report — how signal volume, processing speed and categorisation accuracy are measured.
• Managing Counterparties — adding institutions and keeping their names and aliases current.