<?xml version='1.0' encoding='UTF-8'?>
<feed xmlns:opensearch="http://a9.com/-/spec/opensearch/1.1/" xmlns:arxiv="http://arxiv.org/schemas/atom" xmlns="http://www.w3.org/2005/Atom">
  <id>https://arxiv.org/api/Kpl53GTeIdSNBcPens8nGV2UqYM</id>
  <title>arXiv Query: search_query=all:"sanctions screening"&amp;id_list=&amp;start=0&amp;max_results=10</title>
  <updated>2026-09-28T19:25:03Z</updated>
  <link href="https://arxiv.org/api/query?search_query=all:%22sanctions+screening%22&amp;start=0&amp;max_results=10&amp;id_list=" type="application/atom+xml"/>
  <opensearch:itemsPerPage>10</opensearch:itemsPerPage>
  <opensearch:totalResults>3</opensearch:totalResults>
  <opensearch:startIndex>0</opensearch:startIndex>
  <entry>
    <id>http://arxiv.org/abs/2609.04269v1</id>
    <title>Corporate-Family Resolution Is Not a String-Matching Problem: A Public Benchmark Stratified by Name Visibility</title>
    <updated>2026-09-02T19:16:47Z</updated>
    <link href="https://arxiv.org/abs/2609.04269v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2609.04269v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Deciding whether two supplier records belong to the same corporate family is a prerequisite for spend consolidation, credit exposure aggregation and sanctions screening. It is usually treated as entity matching, but the tasks differ: a family link connects records that are deliberately different entities, and the evidence often appears in neither record. We introduce CorpFam, a public benchmark of 54,864 candidate pairs over 10,307 corporate families, derived from 6,638,350 US federal award records in which every supplier self-reports its ultimate parent to a government registry. Pairs are stratified by name visibility: whether the names are identical after normalisation, share a distinctive token, or share none. Because strata have positive rates from 10.2% to 97.3%, we report per-stratum recall, base-rate invariant, rather than F1, which is not. The strongest of 5 matchers recovers 100.0% of identical pairs and 4.2% of invisible ones; no method exceeds 4.7% on the latter. The failure begins before matching. Blocking decides which pairs a matcher sees, and we evaluate 7 schemes spanning phonetic keys, attribute keys that ignore the name, and semantic nearest neighbours. None reaches three percent on invisible pairs, and their union recovers 6.8%. 93.2% of these links never enter the candidate set, so no matching-stage improvement can reach them. The links are real: against SEC Exhibit 21 subsidiary schedules, which share no provenance with procurement registration, 64.2% of invisible links are corroborated, against 0.16% under permuted parents and 0.41% against the same parent's wrong exhibit: two unrelated nulls agreeing to within 0.25 points. Corporate-family resolution is a retrieval problem misfiled as a matching problem; the intervention point is candidate generation, not ranking. The benchmark, adjudication log, and code reproducing every number are released.</summary>
    <category term="cs.DB" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.IR" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.LG" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.LO" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-09-02T19:16:47Z</published>
    <arxiv:comment>21 pages, 8 tables. Benchmark, full adjudication log, and code reproducing every number: https://github.com/harshitg93/corpfam-benchmark</arxiv:comment>
    <arxiv:primary_category term="cs.DB"/>
    <author>
      <name>Harshit Gupta</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2602.14009v1</id>
    <title>Named Entity Recognition for Payment Data Using NLP</title>
    <updated>2026-02-15T06:28:57Z</updated>
    <link href="https://arxiv.org/abs/2602.14009v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2602.14009v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Named Entity Recognition (NER) has emerged as a critical component in automating financial transaction processing, particularly in extracting structured information from unstructured payment data. This paper presents a comprehensive analysis of state-of-the-art NER algorithms specifically designed for payment data extraction, including Conditional Random Fields (CRF), Bidirectional Long Short-Term Memory with CRF (BiLSTM-CRF), and transformer-based models such as BERT and FinBERT. We conduct extensive experiments on a dataset of 50,000 annotated payment transactions across multiple payment formats including SWIFT MT103, ISO 20022, and domestic payment systems. Our experimental results demonstrate that fine-tuned BERT models achieve an F1-score of 94.2% for entity extraction, outperforming traditional CRF-based approaches by 12.8 percentage points. Furthermore, we introduce PaymentBERT, a novel hybrid architecture combining domain-specific financial embeddings with contextual representations, achieving state-of-the-art performance with 95.7% F1-score while maintaining real-time processing capabilities. We provide detailed analysis of cross-format generalization, ablation studies, and deployment considerations. This research provides practical insights for financial institutions implementing automated sanctions screening, anti-money laundering (AML) compliance, and payment processing systems.</summary>
    <category term="cs.CL" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.AI" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.LG" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-02-15T06:28:57Z</published>
    <arxiv:comment>14 pages, 8 figures, research paper</arxiv:comment>
    <arxiv:primary_category term="cs.CL"/>
    <author>
      <name>Srikumar Nayak</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2512.08083v1</id>
    <title>Exploiting the Randomness of Large Language Models (LLM) in Text Classification Tasks: Locating Privileged Documents in Legal Matters</title>
    <updated>2025-12-08T22:28:49Z</updated>
    <link href="https://arxiv.org/abs/2512.08083v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2512.08083v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>In legal matters, text classification models are most often used to filter through large datasets in search of documents that meet certain pre-selected criteria like relevance to a certain subject matter, such as legally privileged communications and attorney-directed documents. In this context, large language models have demonstrated strong performance. This paper presents an empirical study investigating the role of randomness in LLM-based classification for attorney-client privileged document detection, focusing on four key dimensions: (1) the effectiveness of LLMs in identifying legally privileged documents, (2) the influence of randomness control parameters on classification outputs, (3) their impact on overall classification performance, and (4) a methodology for leveraging randomness to enhance accuracy. Experimental results showed that LLMs can identify privileged documents effectively, randomness control parameters have minimal impact on classification performance, and importantly, our developed methodology for leveraging randomness can have a significant impact on improving accuracy. Notably, this methodology that leverages randomness could also enhance a corporation's confidence in an LLM's output when incorporated into its sanctions-compliance processes. As organizations increasingly rely on LLMs to augment compliance workflows, reducing output variability helps build internal and regulatory confidence in LLM-derived sanctions-screening decisions.</summary>
    <category term="cs.IR" scheme="http://arxiv.org/schemas/atom"/>
    <published>2025-12-08T22:28:49Z</published>
    <arxiv:primary_category term="cs.IR"/>
    <author>
      <name>Keith Huffman</name>
    </author>
    <author>
      <name>Jianping Zhang</name>
    </author>
    <author>
      <name>Nathaniel Huber-Fliflet</name>
    </author>
    <author>
      <name>Fusheng Wei</name>
    </author>
    <author>
      <name>Peter Gronvall</name>
    </author>
  </entry>
</feed>
