Counterparty signing anomaly detection

Counterparty signing anomaly detection compares the people and entities about to sign against your organization's expected signing patterns. It runs after signatory fields are populated and before the document is sent for execution, surfacing mismatches that are easy to miss in a long signature block or a rushed closing packet.

The check does not block release. Counsel and deal teams still decide when a document goes out for signature. The output is a structured quality signal: each flag names the signatory field, states what looked unusual, and cites the anomaly rule ID that fired. When signatory data is incomplete, the check returns empty rather than guessing.

The detection layer focuses on counterparty-side signatories only. Your internal approvers and authorized signers are out of scope here; those belong in signatory authority verification.

Typical inputs include:

• Legal entity name and any DBA or trade name on the signature block
• Individual signer name, title, and email domain
• Jurisdiction or governing law referenced on the document
• Prior signing history for the same counterparty, agreement type, or deal family

Typical outputs are flags such as:

• Wrong entity: the signing company name does not match the counterparty of record on the agreement or in your CRM
• New individual: a person is signing who has not appeared on prior executions with this counterparty
• Unusual jurisdiction: the signer's stated location or the document's execution jurisdiction diverges from historical patterns for similar deals

Each flag is self-contained. A reviewer can read one line, open the cited field, and decide whether the anomaly is explained (reorg, new subsidiary, delegated signatory) or needs a follow-up before countersignature.

Rules are deterministic comparisons against reference data and historical baselines, not open-ended model guesses. Every fired rule produces a record with at least:

| Element | Purpose | | --- | --- | | Signatory field | Where in the packet the value came from (e.g., counterparty.signer.name, counterparty.entity.legalName) | | Observed value | What the document or envelope currently contains | | Expected pattern | What prior deals, master data, or policy would suggest | | Anomaly rule ID | Stable identifier for reporting, playbooks, and audit (e.g., SIGN-ANOM-001) |

Example rule families:

• Entity mismatch (SIGN-ANOM-001): legal name on the signature block differs from counterparty master data or the party listed in the preamble beyond normalized spacing or suffix variants.
• Unknown signer (SIGN-ANOM-002): individual has no prior signed execution for this counterparty entity in the lookback window.
• Title out of band (SIGN-ANOM-003): title is not among roles historically associated with binding signatures for this agreement category.
• Email domain drift (SIGN-ANOM-004): signer email domain does not match the counterparty's primary corporate domain or approved affiliate list.
• Jurisdiction shift (SIGN-ANOM-005): execution jurisdiction or signer country differs from the modal jurisdiction for this counterparty or deal type.

Rules are versioned. When counsel updates a playbook, rule IDs stay stable so trend reports remain comparable quarter to quarter.

An empty result means one of two things, and the UI should make the distinction clear:

1. No anomalies detected — all evaluated rules passed against available reference data.
2. Insufficient signatory data — required fields were missing, unreadable, or not yet extracted, so no rule ran to completion.

Required fields usually include counterparty legal entity name and at least one individual signer identifier (name plus email or title). If your pipeline has not yet run signature block extraction, anomaly detection waits rather than inferring signers from free text.

This behavior protects quality outcomes: an empty list because data was incomplete is not the same as a clean bill of health. Operations teams should treat incomplete extraction as a upstream task, not a green light to skip human review on high-value agreements.

The check sits logically between contract assembly or CLM approval and envelope send. Vendor specifics differ in where signatory fields live and how history is retrieved.

DocuSign — Signers and roles are defined in the envelope before send. Anomaly detection reads recipient names, titles, and routing order from the draft envelope and compares them to counterparty records synced from your CLM or CRM. Completed envelope history in DocuSign supplies prior signer names and email domains for the unknown-signer rules.

Adobe Sign — Agreement templates and participant sets map cleanly to signatory fields. Detection runs on the pre-send agreement object; historical comparisons pull from Adobe Sign's completed agreement archive or a warehouse export if you mirror executions centrally.

Ironclad — Workflow stages already capture counterparty identity and approver lists. Running anomaly detection at the "ready for signature" transition keeps flags inside the same review surface counsel uses for other legal checks, including multi-jurisdiction execution check when governing law and execution location must align.

OneTrust — Privacy and vendor records often hold canonical entity names and primary contacts. Anomaly rules can cross-check signing individuals against approved vendor representatives, which is useful when the counterparty is a processor or sub-processor rather than a traditional customer.

In all four environments, the integration pattern is the same: read draft signatory fields, evaluate rules, attach flags to the deal record, and leave send/release authority with counsel.

The intended outcome is quality, not automatic stop. Flags are advisory inputs at release time:

1. Extraction populates signatory fields (see signature block extractor).
2. Anomaly detection evaluates rules and writes zero or more flags with field citations and rule IDs.
3. Counsel reviews flags alongside authority and jurisdiction checks.
4. Counsel explicitly releases for signature even when flags remain, documenting rationale in the deal system when policy requires it.

Flags compress review time. Instead of re-reading every signature line, counsel starts with structured exceptions. A wrong-entity flag on counterparty.entity.legalName with rule SIGN-ANOM-001 might reflect a harmless recent rename—or a copy-paste error that would bind the wrong subsidiary. A new-individual flag with SIGN-ANOM-002 might be expected after a CFO change—or the first sign of a fraudulent routing attack.

Pair this check with stalled signature detection for post-send monitoring. Anomaly detection catches problems before ink; stalled detection catches process drift after the envelope is live.

Because every flag carries an anomaly rule ID, legal operations can measure which rules fire most often, which deal types generate noise, and where master data needs cleanup. Spikes in SIGN-ANOM-004 (email domain drift) often trace to acquired subsidiaries not yet merged in CRM. Repeated SIGN-ANOM-005 hits may prompt an update to standard jurisdiction language rather than case-by-case waivers.

Tune lookback windows and title allowlists with counsel input. Aggressive unknown-signer rules surface more false positives on small counterparties with limited history; conservative settings risk missing first-time fraud. The rule ID ledger makes those tradeoffs explicit and reversible.

---

Related signing-stage checks

• Signatory authority verification — confirms your side and the counterparty's side have authority to bind the entity.
• Multi-jurisdiction execution check — validates governing law, venue, and execution location consistency.
• Signature block extractor — structured signatory fields required before anomaly rules can run.
• Stalled signature detection — post-send follow-up when countersignature does not complete on time.

[REDACTED]