ESEN
Sales and support 442 138 8102 Request a demo
Fisher Comply · AML and KYC

Know who you deal with: lists, risk and identity in your own ERP.

Two Fisher Platform modules that are purchased together or separately. AML Screening screens your customers, suppliers and staff against official lists and tells you why there is a match. IdVerify verifies identity with INE or passport, with a person who decides. The data stays in your instance.

Book a demo What it does and what it doesn't
  • Matches explained field by field
  • Four eyes and a log that detects tampering
  • No verification is approved on its own
Compliance · OctoberIllustrative view
Juan Pérez EjemploThe CURP matches the list · approved by a second person
Confirmed
Importadora Ejemplo del CentroIdentical name, no RFC on the list · the tax certificate was requested
Under review
Marta López MuestraDocument read, data consistent · awaiting her visual review
Identity
A list changes → only those who resemble are re-screened
What usually happens

Six ways of not knowing who you deal with

Knowing your counterparty is an obligation for many and good practice for everyone. Doing it by hand doesn't scale.

Searching on a site, by hand

Someone types the name into a list's search box, when they remember, and there is no record of which version of the list was consulted.

Lists that change and nobody reviews

You screen on sign-up. Six months later, the list changed and the customer is still there without anyone looking again.

Alerts without explanation

"Matches at 87%": with what? Without knowing why it sounds alike, the analyst dismisses everything or dismisses nothing.

Decisions without a second pair of eyes

A single person confirms or dismisses, and tomorrow nobody knows who, when or with what argument.

IDs over WhatsApp

A blurry photo of the ID card, without consent, without review and stored on someone's phone.

Each area with its own sheet

Sales, purchasing and finance don't see what compliance already knows, and invoices go out or payments are made to someone who shouldn't have received them.

How it all fits together

From creating the record to the decision, without leaving the ERP

Each piece works on its own, but together they close the cycle of knowing your counterparty.

1

Identify

The person uploads their document through a link, their portal or at the counter, with their consent.

2

Screen

Their name, RFC and CURP are compared with the official lists. On sign-up, on edit and when a list changes.

3

Review

Cases are explained and decided by a person; confirmed ones, with a second person.

4

Assess risk

A matrix with its weights and its levels. It defines how often to review again.

5

Act

The gate warns or blocks the invoice or payment, and everything is kept in a log.

Inside the record

Compliance lives where your team already works

It is not another system you have to go to: it is a tab on the customer, supplier, employee and lead record.

admin/clients/client/79
Record of a fictitious customer. AML and identity status in view, the lists consulted with their version and the reason for the risk.
  • Which lists and from what dateEach screening saves the sources and versions it used, so you can prove it later.
  • Beneficial owners and representativesThey are added to the record and are screened too.
  • Screen nowA button to look again without waiting for the queue.
  • On four record typesCustomers, suppliers, staff and leads; also contacts and candidates.
AML Screening · lists

The official lists, downloaded from their source and versioned

  • Sanctions: OFAC (SDN and Consolidated), United Kingdom, European Union, UN, US Consolidated Screening List, Canada (SEMA) and Switzerland (SECO).
  • Mexico: SAT 69-B and 69-B Bis. Those of art. 69 of the CFF (firm credits, not located…) are in the catalog, off by default, and count as tax risk, not as an alert.
  • Your own: an internal house list and a manual upload, for what cannot be downloaded, such as the UIF Blocked Persons List, which is delivered to obligated parties through their own channels.
  • Health of each source: last load, version and changes (what came in, what changed and what left). A load that would remove more than 20% of a list is stopped and warns you.
admin/screening
Dashboard. Cases by status, portfolio and the health of each list with its last load.
Explainable matches

Each alert says why it sounds alike

  • What matched with what: the words of the name, the coverage, and whether the date of birth and country match, against the version of the list that was used.
  • RFC and CURP as exact identifiers. A CURP or RFC identical to one on a list always sounds. From a CURP the date of birth and sex are also deduced.
  • Designed for Hispanic names: reversed order, no accents, no second surname, particles ("de", "del"), one-letter errors and nicknames such as "Chuy" for Jesús.
  • A namesake doesn't get in the way: with a different date of birth, the alert is not raised.
  • Thresholds per source and per subject type, editable, and a set of labeled cases with which the engine is calibrated before changing it.
admin/screening/cases/2
A case under review. Subject and list side by side, the alert's explanation and the decision with its reason. Entries of the internal list, fictitious.
Four-eyes cases

A compliance decision is signed by one person and approved by another

  • Alerts are grouped into one case per person. Each alert is decided: false positive (with its reason), confirmed match or inconclusive.
  • Configurable four eyes: nobody, only confirmed ones (default) or all. Whoever proposed cannot approve, and that is checked on the server, not on the screen.
  • A false positive doesn't sound again as long as neither the person's data nor the list's data change.
  • Audit log chained by fingerprints: if someone alters it by hand, the case record says at which event.
  • PDF certificate with the lists and their versions, the explanation of each match, who decided and who approved.
admin/screening/cases/1
Closed case. Proposed by an analyst and approved by another person; the audit log is verified and says "intact".
Risk and monitoring

A risk level that you define and that is kept up to date

  • Risk-based approach: screening result, country (with the FATF lists, editable), politically exposed person, tax risk, activity, product, channel, beneficial owner, seniority, invoiced volume and identity verification.
  • Weights, points, levels and minimum rules on screen. Each change is a new version: what was already assessed keeps its own.
  • Periodic review by level (by default 36, 12 and 6 months): a nightly task re-screens anyone whose review is overdue.
  • Gate on invoicing and purchasing: issuing an invoice, paying a supplier or registering an order asks first. By default it warns; you decide what it blocks. Authorizing to operate despite a block requires a reason and a second person.
admin/screening/risk
Risk matrix. Editable weights, points and levels, with version.
Everything is a setting: four eyes, tolerances and gate.

PEP, as a complement

Public offices from Wikidata (public domain) and the registry of municipal presidents from INAFED, with relatives and a configurable period. It is not a curated product: see "What it does and what it doesn't".

IdVerify · identity verification

Have the person identify themselves, and have someone review it

A guided flow, a privacy notice with consent and a review screen where each check says what happened and what could not be checked.

1

Consent

Full notice; ID and biometrics in separate boxes, with typed name.

2

Document

Front and back with framing guide and warnings about sharpness, light and glare.

3

Selfie and challenges

If biometrics were authorized: a selfie and movements requested by the server.

4

Checks

Reading of the machine-readable zone, CURP, validity, age, data against the record and screening.

5

Review

One person approves or rejects, with a reason. Optionally, a second one.

Review

Each check, with its result, and what could not be checked, stated

  • Reading on your server of the machine-readable zone of the ID card and passports, with their check digits; OCR confusions are corrected only when the digit confirms it.
  • CURP: check digit and consistency with the date, sex and surname read. Also validity, minimum age, QR, comparison against the record and a warning if the same document was already verified for another person.
  • "Not available" does not count as correct. What could not be checked sends the verification to review, with its reason.
  • Only the rejection is automatic of an expired document or a minor. Approving is always done by a person.
admin/idverify/sessions/1
Review. The face comparison shows "Not available" because there is no face engine: a person compares it.
Images under safekeeping

Images are not for everyone, and each view is logged

  • Encrypted (AES-256-GCM) in a storage destination of its own. Without an encrypted destination, no verification is opened.
  • They are seen only on the review screen, with two permissions (review and view biometrics), with a watermark with the name of whoever is looking and access log.
  • Configurable retention: by default, 10 years in AML flows, 90 days the selfie outside AML and 30 days the frames. Biometric templates are not stored.
  • The holder only sees "under review", "verified" or "could not be completed": never the result of a screening.
Sample images. The ID card is fictitious and carries the label "SAMPLE"; the face is an illustration.
Automatic rejection: expired document.
Sessions and their status.
Flows and providers

You decide what is requested, and who does each part

  • Configurable flows: steps, accepted documents (voter ID, passport, resident card…), liveness check, thresholds, whether it is AML and whether it screens on approval.
  • Four channels: email link, customer portal, counter and hand-off to mobile with a QR code.
  • Providers as pieces: the module brings the interface, the encrypted settings and the receiver of signed notices, but none comes connected. If you contract one, a provider never approves or rejects on its own: its refusals go to review.
  • Optional face engine: an own vision service (Python, on a VPS) to compare and score. Without it, a person compares looking at the images.
admin/idverify/flows/1
Flow editor. The Nominal List and RENAPO appear as "Not checked" as long as there is no agreement.
Settings, with the notice of its limits in view.
No fine print

What it does and what it doesn't

We would rather you know today than in an audit. This is what is implemented and what is not.

What it does

Today, in production
  • Downloads and versions official lists from their source, and re-screens when they change.
  • Compares by name, RFC and CURP, and explains each match.
  • Four-eyes cases, chained audit log and PDF certificate.
  • Configurable risk and a gate on invoicing and purchasing.
  • Reads the ID card and passport, checks check digits, CURP, validity and age.
  • Consent, encrypted images, watermark and access log.
  • Data in your instance: nothing from your portfolio goes out to a third party, unless you choose a provider.

What it doesn't do

Stated clearly
  • It does not validate against INE or RENAPO by default. That requires an agreement (or a provider that has one). The module includes room for your own agreement, with no adapter until the technical annex is available.
  • The built-in liveness check is not certified (iBeta, ISO 30107-3) and does not detect injection attacks, quality forgeries or the NFC chip.
  • Without the vision service, it doesn't compare faces: a person does it by looking at the images.
  • There is no own adverse media. Only through a provider, which is not included.
  • PEPs are a complement, from open sources, not a curated paid-data product.
  • The Blocked Persons List is a manual upload: it cannot be downloaded publicly.
  • It does not "comply with the law for you". It is a tool for your compliance officer; the decision and the responsibility are yours.

More data, if you need it. Whoever needs curated worldwide PEPs can connect OpenSanctions as a paid query with their own account (it comes switched off and each query is charged); whoever needs validation against INE or RENAPO, an agreement of their own or a provider; and whoever needs a certified liveness check, commission that part from a provider. Each piece is turned on without changing the rest.

Part of Fisher Platform

What being inside the ERP means

Invoicing and purchasing

The invoice or payment asks before going out. With Screening inactive, everything works as before.

Anti-Money Laundering

The persons and representatives of Anti-Money Laundering are screened and have their screen, without modifying the module or its FIU filings.

Case files

An "Identity verification" requirement that is requested from its card and is fulfilled on its own when approved, with the certificate attached.

Foreign trade

The 69-B of the customs case file is updated on its own from the SAT's automatic download.

Bastino

Bastino searches the lists, tells you the status of a record and proposes screening or assigning a case. Deciding a case or approving a verification, never: a person signs it.

API, alerts and webhooks

Screening by API with quota per key, in-app alerts and platform events (alert, case decided, verification concluded) for your webhooks.

Next step

How we get started

The two modules are purchased together or separately, and quoted per instance.

1

Demo

A fictitious customer from start to finish: sign-up, screening, case, risk and verification.

2

Your policy

You tell us which lists, which thresholds, what is blocked and who approves. That is configuration.

3

Go-live

First load of lists, compliance roles, a privacy notice approved by your legal area and an encrypted destination.

4

Operation

Your existing portfolio is screened and your team handles the first cases, supported by ours.

Frequently asked questions

What we are usually asked

Does it validate my INE or my CURP against INE or RENAPO?

Not out of the box. Those queries require an agreement with the INE's DERFE or with RENAPO, or a provider that already has one. There is a place to configure an agreement of your own, but no provider comes connected. What it does do is read the document, check its check digits, the consistency of the CURP, the validity and the age, and put everything in front of a person who decides.

Is the liveness check certified?

No. The built-in one has no independent certification and does not detect injection attacks (virtual cameras, real-time deepfakes). Without the optional vision service, face comparison is done by a person. If you need that certification, you can commission that capability from a provider and leave the rest with the built-in engine.

Which lists are checked and how often are they updated?

OFAC (SDN and Consolidated), United Kingdom, European Union, UN, US Consolidated Screening List, Canada (SEMA), Switzerland (SECO) and SAT 69-B and 69-B Bis, downloaded from their official source at the frequency each source allows; each has its own health on screen. The internal list, the manual upload and PEPs from open sources are added.

And the UIF Blocked Persons List?

It is not publicly downloadable: it is delivered to obligated parties through their own channels. That is why it is loaded by hand from the file you receive, with a column mapping that is saved, and it is only seen inside the panel.

Does it deliver worldwide PEPs and adverse media?

Not as an own product. The included PEPs (Wikidata and INAFED) are a complement. Whoever needs curated worldwide coverage can connect OpenSanctions with their own account (paid query, off by default) or a provider. Adverse media does not exist in the module and would only be obtained through a provider.

Where do the data and images stay?

In the database and storage of your instance. Identity images are stored encrypted, with configurable retention, and nothing leaves the server except to the provider you choose in a flow. Artificial intelligence, if you turn it on, only works on text and never on the images.

How much does it cost?

The official lists have no license cost. The price is quoted per instance, with AML Screening and IdVerify together or separately. Get a quote from us according to your volume and your needs.

Book a demo

We will look at your compliance policy and what you do by hand today, and show it to you running with fictitious data.

Fisher Networks ventas@fishernetworks.net 442 138 8102
Send an email
About the screenshots and the data

The screenshots are from a demo environment. All the persons, companies, RFCs and CURPs that appear are fictitious (for example "Juan Pérez Ejemplo"), the entries that produce matches are in the demo's internal list, and the ID cards are sample images generated for the occasion, with the label "SAMPLE"; the faces are illustrations. The names of the official lists and their load dates are real; no screenshot shows a person included in them. References to the LFPIORPI, the SAT or official lists are informational and do not constitute legal advice. "Fisher Comply" is the commercial name under which the AML Screening and IdVerify modules of Fisher Platform are presented.

View plans