Castellum alias matching needs field-level identity evidence
Castellum.AI describes sanctions and politically exposed person screening across many issuer lists, languages, aliases, and enriched identifiers. A potential match still needs a reproducible record of the screened subject, list record, field transformations, score, analyst reasoning, and applicable legal review.
Editorial figure by Trade Controls Brief. Source context: Castellum.AI Sanctions and PEP Screening.
Freeze the subject presented for screening
The direct answer is that alias-aware matching needs a versioned subject record. Preserve whether the subject is a person, legal entity, vessel, location, bank, intermediary, beneficial owner, consignee, employee, supplier, or another role in the proposed activity. Retain the original name and script, normalized representation, aliases, identifiers, birth or establishment information, addresses, nationality or jurisdiction data, ownership links, source system, submitter, transaction or relationship context, and screening time.
Normalization should be visible rather than destructive. Transliteration, punctuation removal, token order, corporate-suffix handling, character substitution, and alias expansion can improve candidate retrieval while also creating false associations. Keep the submitted value beside every transformed value and record which matching configuration used it. A reviewer should be able to reproduce why two records became candidates without treating the transformation as proof that they describe the same subject.
Bind the candidate to one issuer record and snapshot
A candidate result should identify the issuing authority or source, list and program, record identifier, record version or captured snapshot, names and aliases, linked parties, addresses and identifiers, designation or publication date, update time, and source URL. Sanctions, politically exposed person, export-control, forced-labor, and law-enforcement records are not interchangeable legal categories. A unified data structure can support review, but it should not erase each source's authority, jurisdiction, status, scope, and meaning.
When an issuer corrects, adds, or removes data, preserve what the screen used and what changed later. Rescreening should create a new comparison event linked to the earlier disposition, not overwrite it. That history matters when an alias is removed, an identifier is corrected, a program changes, or a party is delisted. The record should show whether an operational action rests on current data, a historical snapshot, or a pending review.
Explain the match without deciding the transaction
The analyst view should expose the compared fields, exact and fuzzy similarities, conflicts, missing values, weighting or threshold version, list coverage, and any automated recommendation. A strong name match with conflicting birth information is different from a weak transliteration match supported by an exact passport number. Preserve the analyst's evidence, identity conclusion, uncertainty, reason, time, authority, escalation, and any request for additional information.
Identity adjudication is only one control. It does not establish ownership or control, program applicability, licensing, exemption, geographic scope, export classification, end use, end user, payment permissibility, or authorization to proceed. Keep the match disposition separate from the accountable legal and business decision for the transaction or relationship. Software can route evidence and enforce a configured hold; qualified owners determine what the governing instruments require.
Test aliases, conflicting identifiers, and a delisting
A representative evaluation should screen the same party in two scripts, introduce a common alias, transpose a birth date, reuse an address across entities, add an exact identifier to a weak name match, change the list snapshot, and then remove the source record. Confirm that transformations remain visible, candidate generation is reproducible, source categories stay distinct, conflicts reach a reviewer, the disposition does not auto-authorize activity, and later list changes preserve the earlier decision context.
Castellum.AI's page supports the attributed provider statements about multi-list screening, aliases, transliterations, enriched identifiers, configurable logic, and structured data. It does not establish source completeness, update latency, matching accuracy, false-positive reduction in a buyer environment, identity, designation applicability, ownership, legal restriction, compliance, transaction disposition, or outcome. Applicability to any party or activity is not established by the public page.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Trade Controls Brief will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.