# Checklynx Checklynx is an AML, sanctions, PEP, adverse media, watchlist, counterparty, and risk-screening platform for regulated and sanctions-exposed businesses. This file includes the main Checklynx page text for AI and LLM analysis, including products, solutions, industries, company pages, pricing, and selected first-party knowledge-base resources. ## Main pages ### Homepage URL: https://checklynx.com/en Checklynx is an AML, sanctions, PEP, adverse media, watchlist, counterparty, and risk-screening platform for regulated and sanctions-exposed businesses. ### Products URL: https://checklynx.com/en/products Explore AML screening products for sanctions, PEP, wanted lists, adverse media, smart matching, screening policies, and AI-assisted review. ### Solutions URL: https://checklynx.com/en/solutions Explore AML screening software for portal, API, CSV, transaction, onboarding, monitoring, case management, customer risk, integrations, and audit evidence workflows. ### Industries URL: https://checklynx.com/en/industries Adapt screening and compliance workflows to the operating realities of regulated financial teams. ### Pricing URL: https://checklynx.com/en/pricing Start with transparent pricing for high-quality risk data, review workflows, monitoring, and audit-ready evidence, then scale as usage grows. Key points: - Base subscription: EUR 49/month. Includes 99 checks per month, core screening workflows, and no long-term lock-in. - Included checks: 99/month. - Included access: Portal, API, batch, monitoring, cases. - Payment options: Stripe, SEPA, AWS, custom. - From 100 checks: EUR 0.10 per check. - From 1,000 checks: EUR 0.08 per check. - From 5,000 checks: EUR 0.05 per check. - From 10,000 checks: EUR 0.03 per check. - Startup program: Special pricing for eligible early-stage teams building regulated products. - Standard pricing: EUR 49/month with 99 included checks and usage tiers for additional volume. - Enterprise contracts: Custom agreements for volume, procurement, security, and support needs. - What is a check?: A check is one billable screening request through the portal, API, or batch workflow. - Included workflow access: Portal access, API, batch checks, customer ongoing monitoring, and case management. Screening source coverage follows the configured workflow. Pricing highlights: - 99 checks/month included in the base subscription. - Core workflow included: portal, API, batch screening, monitoring, and cases. - Startup and enterprise paths for teams with special pricing or procurement needs. Pricing examples: - Example: 300 checks/month: The EUR 49 base subscription includes 99 checks. The remaining 201 checks are billed at EUR 0.10/check. Total: EUR 69.10/month - Example: 1,000 checks/month: EUR 49 base subscription includes 99 checks. Checks 100 through 999 are billed at EUR 0.10/check, and check 1,000 is billed at EUR 0.08/check. Total: EUR 139.08/month ### Checklynx AML Compliance Software Company URL: https://checklynx.com/en/company Learn more about Checklynx, our security posture, and how to contact the team. Key points: - About - Contact ### Contact URL: https://checklynx.com/en/contact Contact Checklynx to discuss screening, onboarding, monitoring, or compliance workflow requirements. ## Products ### Sanctions Screening Software & Tools URL: https://checklynx.com/en/products/sanctions Try sanctions screening software and tools for customers, companies, UBOs and counterparties, with API, batch, portal, monitoring and review evidence. Key points: - Global sanctions coverage - False-positive suppression - API, batch and portal screening - Case and audit evidence ### PEP Screening Software URL: https://checklynx.com/en/products/pep Identify and monitor politically exposed persons, relatives, and close associates with role context, customer-risk review, cases, and audit evidence. Key points: - PEP screening software - RCA context - Ongoing PEP monitoring - Case and audit evidence ### Wanted List Screening Software URL: https://checklynx.com/en/products/wanted Screen people and entities against wanted persons, law enforcement, and criminal watchlist data as part of AML review. Key points: - Wanted persons data - Criminal watchlist data - Source-backed match context - Review evidence ### Adverse Media Screening Software URL: https://checklynx.com/en/products/adverse-media Screen trusted media and official sources for negative news, financial-crime risk, regulatory signals, and source-backed review evidence. Key points: - Negative news screening - Risk category tagging - Noise reduction - Case and audit evidence ### AML Screening Policy Management Software URL: https://checklynx.com/en/products/screening-policies Define screening coverage, cadence, customer scope, and review routing across batch, monitoring, API, and case workflows. Key points: - Screening profiles - Monitoring policies - Customer and cohort scope - Case routing and false-positive suppression ### AI Result Assessment for AML Screening URL: https://checklynx.com/en/products/ai-result-assessment Use AI to explain exploratory search results while keeping matching, decisions, and case review under reviewer control. Key points: - Exploratory result explanations - Reviewer-controlled assessment - Search context summary - No automated compliance decisions ### AML Name Matching Software URL: https://checklynx.com/en/products/smart-matching-technology AML name matching software for sanctions and PEP screening. Compare aliases, spelling variants, transliterations, scripts, and identifiers in scored profiles. Key points: - Multi-source profile clustering - Standardized identity signals - Profile-level match scoring - MLRO-ready risk context ## Solutions ### AML Screening Portal for Customer and Counterparty Checks URL: https://checklynx.com/en/solutions/screening-portal Run browser-based sanctions, PEP, watchlist, wanted-list, and adverse-media checks without building an integration. Review people, companies, vessels, aircraft, passports, IBANs, and counterparties with the source context attached. Key points: - Exploratory subject searches - Person, entity, vessel, passport, and IBAN checks - MLRO review context - Onboarding, CDD, and EDD evidence Detail: Screen and review a subject without building an integration The Checklynx screening portal gives compliance teams a direct workspace for one-off customer and counterparty checks. Search a subject, compare possible matches, inspect source evidence, record the outcome, and retain a report for onboarding, CDD, EDD, or investigation work. Workflow: From exploratory search to documented reviewer outcome Search the party and available identifiers, review grouped results across the selected risk sources, record the MLRO or analyst decision, and retain the inputs and evidence behind it. Can screen or support: - Broad inputs: Search names, entities, vessels, passports, and IBANs - MLRO access: Support senior compliance review - Review: Inspect source-backed sanctions, PEP, wanted, and adverse media results - PDF report: Export MLRO decisions with analysis inputs Capabilities: - Search more than customer names: Screen individuals, businesses, vessels, aircraft, passports, IBAN accounts, aliases, nationalities, and related counterparties from one review surface. - Support MLRO judgment: Give the MLRO and compliance reviewers source context, identifiers, match strength, adverse signals, and relationship data before deciding whether to approve, reject, escalate, or monitor. - Generate decision reports: Create a PDF report that captures the MLRO decision, analysis inputs, search parameters, source context, notes, and timestamps for onboarding, CDD refreshes, EDD, and investigations. Workflow moments: - Search subject: Person, company, vessel, aircraft, passport, IBAN, alias, or counterparty Exploratory screening request. - Result review: Source records, aliases, identifiers, list categories, scores, adverse signals MLRO-ready context. - Use case: Onboarding, CDD refresh, EDD, investigation, exception handling Risk-based review path. - PDF decision report: MLRO decision, analysis inputs, notes, timestamps, filters, source context Downloadable decision evidence. FAQs: - What is an AML screening portal? An AML screening portal is a browser-based workspace where authorised compliance users can screen customers and counterparties, inspect possible sanctions, PEP, watchlist, wanted-list, and adverse-media matches, and record the reviewer outcome without first building an API integration. - Who can be checked in the screening portal? Teams can search people, companies, counterparties, vessels, aircraft, passports, IBANs, aliases, nationalities, and other available identifiers. The appropriate subjects and sources depend on the organisation’s risk-based screening policy. - Can the portal be used for customer onboarding and EDD? Yes. Compliance teams can use it for onboarding checks, CDD refreshes, enhanced due diligence, investigations, exception handling, and other controlled one-off reviews where a human needs to inspect and document the result. - Does portal screening replace ongoing monitoring? No. Portal screening supports direct and exploratory checks at a point in time. Ongoing monitoring re-screens approved records when source data, customer information, or a configured review cadence changes. - What evidence can be retained after a portal check? A review can retain the search inputs, selected sources, possible matches, source context, reviewer notes, outcome, timestamps, and a decision report so the organisation can explain how the result was handled. ### AML Screening API URL: https://checklynx.com/en/solutions/real-time-screening-api Run real-time AML, sanctions, KYC, watchlist, and transaction screening checks from your product, backend, or onboarding flow. Key points: - AML screening API - Sanctions and KYC checks - Transaction screening events - Developer documentation ### Agentic AML via MCP URL: https://checklynx.com/en/solutions/agentic-aml Connect authorised AI agents to governed Checklynx screening and research capabilities while keeping compliance decisions under human control. Key points: - Authorised agent access - Governed screening and research tools - Human review and escalation - Traceable compliance evidence ### AML Transaction Screening Software for Payments and Counterparties URL: https://checklynx.com/en/solutions/transaction-screening Screen the supplied parties, names, and supported identifiers in payment, payout, transfer, remittance, wallet, and counterparty events. Route potential sanctions and watchlist matches for human review before value moves. Key points: - Sanctions and watchlist checks - Crypto wallet screening - Counterparty screening - Evidence for held or cleared transactions Detail: Check the parties and identifiers attached to a transaction A payment event can involve an originator, beneficiary, counterparty, account, wallet, or other supplied identifier. Checklynx screens the submitted parties and supported fields against enabled risk sources, returns structured results, and keeps the screening evidence connected to the business event. Workflow: From payment event to controlled release or review Submit the relevant transaction parties and identifiers, screen them against the enabled sources, apply your routing rules, and retain the result and authorised decision with the transaction record. Can screen or support: - Inline: Screen before payment release - Context: Parties, wallets, and transaction fields - Routing: Clear, hold, review, or escalate - Evidence: Keep screening and decision records Capabilities: - Stop prohibited activity earlier: Screen counterparties, beneficiaries, senders, receivers, wallets, and relevant transaction context before the workflow completes. - Give operations a clear next step: Return structured results that can hold a payment, continue a low-risk flow, or create an analyst review task. - Keep a defensible payment record: Attach screening inputs, matched sources, timestamps, and review outcomes to the transaction history. Workflow moments: - Payment initiation: Checkout, payout, transfer, remittance, wallet event Screen parties and context before release. - Risk response: Results, match profiles, source types, identifiers Route the payment to clear, hold, or review. - Compliance review: Case queue, analyst notes, escalation Resolve potential matches with evidence attached. - Audit trail: Request, response, decision, timestamps Reconstruct what happened if challenged. FAQs: - What is AML transaction screening software? AML transaction screening software checks the parties, names, counterparties, and supported identifiers supplied with a payment or transfer event against enabled sanctions, watchlist, and other screening sources. Potential matches can be held or routed for human review according to the organisation’s policy. - Which transaction parties can be screened? The submitted data may include originators, senders, receivers, beneficiaries, counterparties, payment parties, companies, and supported account or wallet identifiers. The organisation remains responsible for deciding which parties and fields must enter scope for each payment flow. - When should transaction screening run? Common checkpoints include beneficiary creation, payment initiation, payout approval, transfer execution, remittance processing, wallet events, counterparty acceptance, and other moments before funds or value are released. - Is transaction screening the same as transaction monitoring? No. Checklynx transaction screening checks supplied parties and supported identifiers against screening sources. Behavioural transaction monitoring analyses activity patterns, amounts, velocity, typologies, and anomalies and requires separate controls or systems. - Does a potential match automatically block a payment? No. Checklynx returns screening results and review context. The customer’s policies and systems determine whether to continue, hold, reject, investigate, or escalate a transaction, and accountable people remain responsible for consequential compliance decisions. Operational handoff: Connect transaction decisions to cases and webhooks Transaction screening is most useful when the result changes what the business system does next. Checklynx connects the screening result to case management and webhook updates so payment, product, and compliance teams stay aligned. - Case management handoff: When a transaction or counterparty needs review, the result can become an owned case with hit context, notes, timeline activity, attachments, escalation, and final disposition. Compliance teams review the evidence while the payment workflow remains held or controlled. - Webhook-driven workflow updates: Use webhooks to notify downstream systems when screening events, review outcomes, or case status changes need to update payment holds, customer records, operational dashboards, or audit workflows. Operational handoff rows: - Potential match: Create or update a case Analyst owns review with evidence attached. - Review outcome: Send event through webhook handoff Payment or product workflow can clear, hold, or escalate. - Case status change: Notify operational systems Dashboards and records stay aligned with compliance work. ### CSV Batch Screening Software for Customers and Counterparties URL: https://checklynx.com/en/solutions/csv-batch-screening Upload a defined population and screen customers, companies, suppliers, or counterparties for sanctions, PEP, wanted-list, and watchlist risk. Review grouped results without searching every record manually. Key points: - Bulk screening uploads - Customer refresh workflows - Downloadable results - Review-ready evidence Detail: Screen a defined population from one controlled CSV upload CSV batch screening supports migrations, remediation, periodic customer reviews, supplier checks, and controlled pilots. Use stable record references, apply a consistent screening policy, review potential matches, and retain the result against the submitted population. Workflow: From customer file to reviewed batch results Prepare the population and stable record references, upload or update the records, apply the selected screening policy, and route possible matches into review while retaining completed outcomes. Can screen or support: - Thousands: Screen large customer files - Upsert: Add or update customer records - Policy: Run once or schedule recurring checks - Suppress: Stop repeating known false positives Capabilities: - Solve periodic screening at scale: Upload a customer base by CSV, keep records updated, and screen thousands of people or companies without asking analysts to search one row at a time. - Choose one-off or policy-driven runs: Run a file once for remediation, migration, or a monthly refresh, or configure a monitoring policy that keeps the same customer base on a recurring screening cycle. - Reduce repeated false-positive work: When reviewers mark a hit as a false positive for a customer, that match can be ignored for future runs so the team does not pay the same review cost every period. Workflow moments: - Import customer base: CSV upload, customer records, cohort membership Create or update the population to screen. - Screen once or schedule: One-off screening run or recurring monitoring policy Run periodic checks without manual searching. - Review hits and cases: Customer-level results, case queue, source evidence Analysts focus only on records that need attention. - Suppress known false positives: False-positive decision and customer match ignore Future runs avoid repeating the same non-risk hit. FAQs: - What is CSV batch screening? CSV batch screening lets a compliance team upload a defined population of customers, companies, suppliers, or counterparties and screen those records together against the enabled sanctions, PEP, wanted-list, and watchlist sources. - What can CSV batch screening be used for? Common uses include customer-base remediation, data migration, supplier or counterparty screening, periodic reviews, and controlled pilots. It suits a known population that can be prepared as a file and does not require an immediate API response for every record. - What information should the CSV file contain? Include a stable internal record reference and the strongest lawfully available identity data, such as full name, entity type, date of birth, nationality, company registration data, and other supported identifiers. Better input data gives reviewers more context for distinguishing possible matches. - Can a later CSV upload update existing customer records? Yes. Stable record references allow an upload to add or update records in the screening population. This keeps later screening results and review history connected to the correct internal customer, supplier, or counterparty record. - Which risk sources can be checked in a batch? A batch can use the sanctions, PEP and RCA, wanted-list, and watchlist sources enabled for the organisation’s screening policy. The appropriate coverage should follow the organisation’s risk assessment and operating requirements. - Can reviewed false positives be retained for later runs? Yes. A resolved false-positive decision can remain connected to the customer and candidate match, so an unchanged non-match does not have to return as entirely new review work on every recurring run. - What evidence is retained after a CSV screening run? The workflow can retain the submitted record reference, screening result, matched source context, reviewer outcome, rationale, and case history. This creates a traceable record of what was screened and how potential matches were handled. - Should we use CSV batch screening, the portal, an API, or ongoing monitoring? Use CSV for a defined uploaded population, the portal for direct one-off searches, the real-time API for event-driven checks inside an operational flow, and ongoing monitoring for maintained records that must be re-screened when data or a configured cadence changes. Operational handoff: The efficient middle ground between manual search and full automation CSV batch screening gives compliance teams a practical operating model for periodic screening. It is faster and more controlled than manual portal searches, while still lighter to implement than full real-time onboarding or ongoing monitoring integrations. - Periodic customer-base refreshes: For companies with thousands of customers, monthly or quarterly screening creates a large repeat workload. CSV import lets the team upload, upsert, and refresh that base, then screen it consistently from one controlled run. - Review once, save future effort: Each potential match can become review work with evidence and case context. When a reviewer decides a match is a false positive for that customer, future runs can avoid raising the same hit again, reducing analyst time and review cost. Operational handoff rows: - Customer file changes: Upload or upsert CSV records The screening base stays current. - Periodic compliance requirement: Run now or attach a monitoring policy Customers are re-screened on the required cadence. - Repeated non-risk match: Mark false positive for that customer The same hit does not keep returning every cycle. ### AML Compliance Software for Screening, Monitoring and Case Review URL: https://checklynx.com/en/solutions/aml-compliance Connect customer and counterparty screening, ongoing monitoring, case review, and audit-ready evidence in one operating model. Keep the subject, source context, reviewer decision, and subsequent changes linked throughout the customer lifecycle. Key points: - Customer and entity screening - Ongoing monitoring - Case review - Audit-ready records Detail: Bring fragmented screening and review controls into one operating model Checklynx connects the screening access method, enabled risk sources, customer or counterparty record, human review, monitoring policy, and retained evidence. Each specialist control keeps its own purpose while the decision history stays connected. Workflow: From customer event to reviewable evidence Start with an onboarding, customer, counterparty, payment-party, or periodic-review event. Run the appropriate screening check, route potential matches to accountable people, retain the outcome, and return relevant changes for later review. Can screen or support: - Coverage: Sanctions, PEP, wanted, adverse media - Workflow: Screening to case review - Monitoring: Keep risk current - Audit: Evidence for governance Capabilities: - Connect specialist controls: Keep sanctions, PEP, wanted-list, adverse-media, customer-risk, and case processes distinct while connecting their relevant outcomes to the same customer record. - Give analysts complete review context: Bring grouped candidate profiles, source records, identifiers, previous decisions, and case history together so reviewers do not rebuild the evidence for every check. - Keep decisions traceable over time: Preserve what was screened, which policy applied, who reviewed the result, what they decided, and which later change caused another review. Workflow moments: - Identify the subject and event: Customer, company, UBO, related party, counterparty, or supplied payment party The screening scope is explicit. - Run the appropriate check: Portal, API, CSV, or monitoring against enabled risk sources Results remain connected to the business event. - Review potential matches: Candidate profile, source context, identifiers, notes, and escalation An accountable person records the outcome. - Retain and revisit: Policy, request, response, decision, timestamps, and case history Relevant changes can return with the earlier context attached. FAQs: - What is AML compliance software? AML compliance software supports defined controls such as customer and counterparty screening, customer risk assessment, case review, ongoing monitoring, and evidence retention. It helps a compliance team operate and document those controls; it does not replace the organisation’s legal analysis, risk assessment, policies, or accountable decisions. - Which AML controls does Checklynx connect? Checklynx connects sanctions, PEP and RCA, wanted-list, watchlist, and adverse-media screening with customer-risk assessment, case management, ongoing monitoring, and retained audit evidence. Each control remains distinct while relevant results stay connected to the customer or business event. - Can Checklynx fit into an existing KYC or compliance stack? Yes. Teams can begin with browser-based portal checks or CSV population screening and connect event-driven checks through an API. Webhooks, cases, monitoring, and evidence can then support the downstream systems and review processes already in use. - Does AML compliance software make the final compliance decision? No. Checklynx prepares screening results, source context, review history, and workflow signals. Authorised people apply the organisation’s policy and remain responsible for decisions such as approval, escalation, enhanced due diligence, rejection, or reporting. - How are false positives handled across later reviews? A reviewed false-positive outcome can remain linked to the customer and candidate match. If the relevant data has not changed, the previous decision can reduce repeated work; new or changed information can return to the review process with the earlier context attached. - What evidence can be retained for audit and governance? The record can include the subject and event, selected policy and sources, request and response, candidate source context, reviewer, notes, justification, outcome, timestamps, and case history. The exact retention and access rules remain under the customer’s governance. - Is this page an AML compliance guide? No. This page explains how Checklynx supports an AML operating model as software. The practical AML compliance guide covers the broader programme responsibilities, legal perimeter, risk assessment, due diligence, escalation, governance, and testing. Operational handoff: Technology prepares the record; accountable people make the decision Checklynx can organise source-backed results, retain previous outcomes, and route changed risk signals. The customer defines the screening policy, decides which parties and events are in scope, and remains responsible for consequential compliance decisions. - Consistent policy execution: Apply approved source coverage, matching settings, review routing, and monitoring cadence through the access method suited to each workflow. - Human-owned review: Potential matches, higher-risk records, and relevant changes move to authorised analysts with the source and decision context attached. Operational handoff rows: - Screening configuration: Customer policy and enabled sources The organisation controls scope and thresholds. - Potential match: Grouped result and source evidence An authorised person reviews the candidate. - Recorded outcome: Decision, justification, case history, and timestamps The control can be tested and explained later. ### KYC & KYB Onboarding Software for AML Risk Decisions URL: https://checklynx.com/en/solutions/kyb-kyc-onboarding Screen customers, businesses, UBOs, and related parties, combine the results with customer risk assessment, and move onboarding decisions through review with evidence ready from day one. Key points: - Client or upstream supplied identity and ownership data - Customer, business, UBO, and related-party screening - Customer risk assessment and case review - Decision evidence and ongoing monitoring Detail: Make onboarding decisions with the full customer context Give compliance teams one place to review screening results, ownership context, customer risk, exceptions, and supporting evidence before the relationship moves forward. Workflow: A clearer path from onboarding to monitoring Connect each onboarding step so reviewers can see who was screened, what influenced risk, which exceptions were investigated, and what evidence supports the recorded outcome. Related workflow: Explore the controls behind each onboarding decision See how Checklynx connects ownership, customer risk, case review, audit evidence, ongoing monitoring, and integrations. Can screen or support: - Faster review: Bring screening and risk together - Complete context: Customers, businesses, UBOs, and related parties - Controlled decisions: CRA, cases, and escalation - Built-in evidence: Decision history and ongoing monitoring Capabilities: - Screen every relevant party: Check customers, businesses, UBOs, controllers, directors, signatories, sellers, beneficiaries, and counterparties in the same onboarding journey. - See ownership in context: Connect ownership and related-party details to the customer record so reviewers can understand who sits behind the business. - Make customer risk consistent: Use customer segment, country risk, sanctions and PEP results, thresholds, factor weights, and risk bands to support repeatable review. - Resolve exceptions with evidence: Assign potential matches and higher-risk records to controlled cases with notes, escalation, review history, CRA snapshots, and timestamps. Workflow moments: - Build the customer record: Connect the customer or business with UBOs, controllers, directors, signatories, and other related parties A single view of the relationship. - Run screening: Screen the relevant people and businesses against the selected sources Results attached to the onboarding record. - Assess customer risk: Apply customer segment, country risk, sanctions and PEP results, thresholds, and configured factors A consistent risk outcome for routing. - Review exceptions: Open assigned cases for potential matches or higher-risk records, with notes and escalation A clear next action for the reviewer. - Record the outcome: Keep screening evidence, the CRA snapshot, case history, profile versions, and timestamps together A traceable decision record. - Monitor changes: Continue screening approved customers, businesses, UBOs, and related parties when configured events occur Risk changes return to review. FAQs: - What is KYC and KYB onboarding software? KYC and KYB onboarding software coordinates customer or business data, relevant related parties, screening results, customer-risk assessment, exception review, and retained evidence before an account or relationship is approved. Checklynx supports the screening, risk, review, and evidence layers within that process. - What is the difference between KYC and KYB onboarding? KYC onboarding focuses on an individual customer and the information needed to assess that relationship. KYB onboarding focuses on a business and may also involve supplied company details, UBOs, controllers, directors, signatories, and other related parties. The exact checks depend on the organisation’s legal obligations and risk-based policy. - How does Checklynx fit into an existing onboarding stack? Checklynx brings screening, customer risk assessment, case review, evidence, and ongoing monitoring into the KYC/KYB workflow. It keeps customer, company, ownership, and related-party context connected so teams can make and evidence consistent decisions. - Can customers, businesses, UBOs, and related parties be reviewed together? Yes, when those records and relationships are supplied to Checklynx. The platform keeps the customer or business connected with the relevant UBOs, controllers, directors, signatories, beneficiaries, and counterparties, then preserves their screening and review context. It does not independently discover or verify ownership. - Which onboarding parties can be screened? The submitted population can include individual customers, companies, UBOs, controllers, directors, signatories, beneficiaries, sellers, suppliers, and other counterparties. Teams choose which roles and risk sources apply to each onboarding journey through their policy. - How are potential matches and higher-risk customers handled? Potential matches and higher-risk records can move into assigned cases with priority, notes, evidence, escalation, and decision history. Reviewers apply the organization’s policy and record the outcome and rationale in the customer record. - Can Checklynx continue monitoring after onboarding? Yes. Approved customers, businesses, UBOs, and related parties can remain in ongoing monitoring, with configured source changes, customer events, and review schedules returning relevant risk changes to the team. - What onboarding evidence can be retained? The record can retain the submitted party data and role, screening policy and sources, candidate context, CRA snapshot, reviewer notes, escalation, outcome, timestamps, profile versions, and case history. The customer controls retention periods, access, and downstream use under its governance requirements. Operational handoff: Use supplied identity and ownership data without confusing screening with verification Checklynx screens the customer, company, UBO, controller, director, signatory, beneficiary, or related party data supplied by the customer or an upstream system. Identity verification, ownership discovery, document validation, source-of-funds work, and legal approval remain separate controls. - Keep party roles explicit: Preserve whether a screened person or company is the customer, UBO, controller, director, signatory, beneficiary, or another related party so the reviewer understands why the result matters. - Route exceptions with context: Move potential matches and higher-risk records into an assigned case with the submitted data, source evidence, customer-risk context, notes, and decision history attached. Operational handoff rows: - Upstream customer data: Identity, company, ownership, and related-party information supplied to Checklynx The party and its role enter the onboarding record. - Screening and CRA: Enabled risk sources, customer segment, configured factors, and review rules Potential matches and higher-risk outcomes follow the approved route. - Authorised decision: Reviewer outcome, justification, escalation, and supporting evidence The onboarding system receives a controlled result while responsibility remains human. ### Customer Risk Assessment Software for Explainable AML Decisions URL: https://checklynx.com/en/solutions/customer-risk-assessment Use Checklynx CRA to classify customer risk with configurable profiles, thresholds, factor weights, and risk bands across country risk, customer segment, sanctions, PEP exposure, and review evidence. Key points: - Configurable risk profiles - Country, segment, sanctions, and PEP inputs - Risk bands and thresholds - Audit-ready CRA snapshots Detail: Replace spreadsheet scoring with a controlled risk outcome Customer risk assessment is not just a score. It is the controlled decision layer that turns customer attributes, screening results, and analyst context into a consistent risk outcome that can be reviewed later. Workflow: From evidence to risk band CRA reads the customer profile and latest screening evidence, applies the active risk profile, resolves factor contributions, and stores the outcome as an auditable snapshot. Related workflow: Connect CRA to onboarding, ownership, monitoring, and evidence Customer risk assessment is strongest when it is fed by KYB/KYC, ownership context, screening, monitoring, cases, and audit history. Can screen or support: - Configurable: Profiles, weights, and thresholds - Inputs: Country, segment, sanctions, PEP - Outcome: Low, medium, high, or prohibited - Evidence: Snapshots, versions, timestamps Capabilities: - Make risk assessment consistent: Apply the same CRA profile logic across customers so analysts do not rebuild risk decisions manually in spreadsheets. - Configure the model to match policy: Set customer scope, thresholds, factor weights, risk bands, and prohibited conditions for individual and entity profiles. - Use live compliance evidence: Bring country risk, customer segment, sanctions exposure, PEP exposure, and reviewer evidence into the customer risk outcome. - Keep the decision audit-ready: Store CRA snapshots with profile version, input evidence, timestamps, scores, bands, notes, and review history. Workflow moments: - Customer profile: Customer type, segment, jurisdiction, country fields Defines the applicable CRA scope. - Screening evidence: Sanctions and PEP exposure from latest reviewed evidence Feeds risk factors from compliance results. - Risk model: Weights, thresholds, bands, hard stops, prohibited conditions Applies the active CRA profile. - Risk outcome: Low, medium, high, or prohibited customer risk Routes onboarding, review, or monitoring work. - Snapshot retained: Inputs, score, profile version, timestamp, notes, audit events Explains the decision later. FAQs: - Why does CRA matter commercially? CRA gives compliance and risk teams a repeatable way to decide which customers can move forward, which need review, and which fall outside risk appetite. The value is not the score itself; it is the ability to turn policy, evidence, and reviewer context into a consistent decision that the business can explain later. - How does CRA reduce spreadsheet scoring? Instead of maintaining formulas, thresholds, and exceptions in spreadsheets, CRA profiles define the factors, weights, risk bands, and prohibited conditions inside the workflow. Analysts see the resolved inputs and outcome, while the system retains the model version and evidence that produced the result. - Can the risk model match our policy? Yes. CRA profiles can be configured around customer type, country risk, customer segment, sanctions exposure, PEP exposure, thresholds, weights, bands, and hard stops. That lets the operating model reflect your risk appetite instead of forcing every customer through the same generic scoring logic. - Can the decision be defended later? Yes. Checklynx stores the CRA snapshot, profile version, resolved inputs, factor contributions, timestamps, screening evidence, reviewer notes, and audit events. Teams can reconstruct why the customer received a low, medium, high, or prohibited outcome at that point in time. - What is customer risk assessment software? Customer risk assessment software applies a configured risk methodology to available customer attributes, screening evidence, and other approved factors. It produces a repeatable risk outcome for review while retaining the inputs, model version, and decision evidence needed to explain that outcome later. - Do sanctions or PEP results automatically determine customer risk? Not necessarily. Sanctions and PEP exposure can be configured as factors, thresholds, or prohibited conditions according to the organisation's policy. Potential matches should follow the relevant review process, and an authorised reviewer remains responsible for the final decision. - When should a customer risk assessment be recalculated? Teams can reassess a customer when relevant customer data changes, reviewed screening evidence changes, a scheduled review becomes due, or a new risk-profile version is intentionally applied. The appropriate triggers and frequency depend on the organisation's risk-based policy. - What is the difference between customer risk assessment and screening? Screening checks a person or company against enabled risk sources and returns potential matches for review. Customer risk assessment combines approved customer attributes, reviewed screening evidence, and configured policy factors into a broader customer risk outcome. The two controls are connected but have different purposes. Operational handoff: Keep model logic, evidence, and human decisions clearly separated Checklynx applies the active customer risk profile to the data and reviewed screening evidence available at that point in time. The model supports a consistent assessment; an authorised reviewer remains responsible for exceptions, escalation, and the final customer decision. - Control model changes: Version profiles, weights, thresholds, bands, and prohibited conditions so teams can identify which logic produced each customer risk outcome. - Preserve reviewer judgement: Keep overrides, notes, escalation, and supporting evidence with the CRA snapshot instead of hiding judgement inside a spreadsheet or disconnected approval. Operational handoff rows: - Configured policy: Applicable customer profile, factors, weights, thresholds, bands, and hard stops Defines how available inputs are assessed. - Calculated assessment: Resolved factors, score, risk band, and model version Produces a consistent result for review and routing. - Authorised review: Exception decision, rationale, escalation, and supporting evidence Records the human outcome and preserves accountability. ### UBO and Related-Party Management Software for AML Review URL: https://checklynx.com/en/solutions/ubo-related-parties Use Checklynx to record ownership and related-party information supplied by your team or upstream systems, represent UBOs, controllers, directors and signatories, and connect that context to onboarding, screening, cases and customer risk assessment. Key points: - UBO and control representation - Supplied ownership chains - Related-party context - Screening and risk evidence Detail: Make ownership context part of the compliance workflow UBO management is not just storing names. It keeps supplied ownership and control relationships, party roles and supporting evidence available to compliance reviewers. Workflow: From ownership structure to review context Capture supplied related parties, assign roles and control types, represent direct and indirect ownership, and keep the resulting structure available for onboarding, screening, case review and customer risk assessment. Ownership discovery, verification and legal analysis remain separate controls. Related workflow: Connect ownership context to onboarding, CRA, cases, and evidence UBO and related-party data becomes more valuable when it feeds customer due diligence, customer risk assessment, ongoing monitoring, and audit evidence. Can screen or support: - Ownership: UBOs and control structure - Roles: Directors, signatories, related parties - Context: Direct and indirect relationships - Evidence: Versions, notes, timestamps Capabilities: - Keep related parties connected to the customer: Record supplied UBOs, shareholders, controllers, directors, authorised signatories, representatives, trustees, protectors and other related parties with their stated roles. - Represent direct and indirect ownership: Capture ownership percentages, effective ownership, control types, source, status, start dates, notes, and relationship paths. - Connect ownership to risk review: Use ownership and related-party context during onboarding, screening review, case handling, and customer risk assessment. - Keep ownership evidence traceable: Preserve versions, timestamps, notes, sources, relationship changes, and audit events so reviewers can explain the structure later. Workflow moments: - Entity customer: Company, jurisdiction, registration, customer record Defines the subject under review. - Related parties: UBOs, directors, signatories, controllers, representatives Adds the people and companies connected to the customer. - Ownership structure: Direct, indirect, effective ownership, control type Shows how control or benefit flows through the structure. - Risk context: Screening status, CRA outcome, notes, source, status Supports onboarding and review decisions. - Evidence retained: Versions, timestamps, relationship changes, audit events Explains the ownership review later. FAQs: - Why separate ownership from basic KYB? KYB identifies the business. Ownership and related-party management explains who owns, controls, signs for, benefits from, or materially relates to that business. That distinction matters because hidden risk often appears through the people and companies behind the customer, not only in the customer record itself. - How does ownership context change risk review? Ownership context helps analysts see whether a customer’s risk changes because of shareholders, directors, signatories, parent companies, indirect owners, representatives, or other related parties. That context can be reviewed alongside screening, cases, monitoring, and CRA evidence before the relationship is approved. - Can indirect ownership be represented? Yes. Checklynx can represent direct and indirect relationships, ownership percentages, effective ownership, role types, control types, source, status, dates, notes, and relationship paths. The goal is to preserve both the structure and the evidence that supported the review. - Does Checklynx automatically apply OFAC’s 50 Percent Rule? No. Checklynx can record, represent and screen ownership and related-party information supplied by the customer or an upstream data source. OFAC’s US-specific rule treats an entity owned directly or indirectly, individually or in aggregate, 50% or more by one or more blocked persons as blocked. Checklynx does not independently discover or verify the complete ownership structure or determine whether the rule applies. The customer remains responsible for establishing the ownership facts and making the legal determination. - What is UBO and related-party management software? UBO and related-party management software keeps supplied information about owners, controllers, directors, signatories, representatives, and other connected people or companies linked to the relevant customer or entity. It helps compliance teams review relationships, screening evidence, customer-risk context, changes, and decision history in one controlled record. - Which related-party roles can Checklynx represent? The supplied structure can include beneficial owners, direct and indirect shareholders, controllers, directors, authorised signatories, representatives, trustees, protectors, parent companies, and other related parties. The organisation decides which roles and evidence are required for each customer type and jurisdiction. - Can UBOs and related parties be screened? Yes. Supplied people and companies can be connected to the customer record and screened against the enabled risk sources. Potential matches remain candidates for review; screening does not itself verify ownership, establish identity, or make the final legal or onboarding decision. - How are ownership changes handled? New or amended ownership and control information can be recorded with its source, effective dates, status, notes, and relationship path. Relevant changes can return to screening, customer risk assessment, or case review under the organisation's configured process, while prior versions remain available as evidence. - Does Checklynx discover or verify beneficial owners? No. Checklynx records, represents, and connects ownership and related-party information supplied by the customer or an upstream source. Ownership discovery, identity and document verification, registry reconciliation, source-of-funds work, and jurisdiction-specific legal analysis remain separate controls. Operational handoff: Make supplied ownership data usable without overstating what the system verifies Checklynx records and represents ownership, control, and related-party information supplied by your team or upstream systems. Establishing the complete ownership facts, validating documentary evidence, resolving conflicts, and making jurisdiction-specific legal determinations remain separate customer controls. - Keep provenance attached: Record the source, status, dates, notes, and reviewer context for supplied ownership and control relationships so teams can see what the structure is based on. - Escalate uncertainty: Route incomplete, conflicting, complex, or potentially relevant ownership information to an authorised reviewer rather than treating a percentage field as a final conclusion. Operational handoff rows: - Upstream ownership information: Supplied owners, percentages, control roles, relationship paths, sources, and dates Creates the structure available for review. - Connected compliance checks: Screening status, customer-risk context, cases, and supporting evidence Shows why a related party may affect the relationship. - Authorised determination: Validation, legal analysis, escalation, rationale, and final decision Keeps responsibility with the customer's approved process. ### AML Ongoing Monitoring Software URL: https://checklynx.com/en/solutions/ongoing-monitoring Monitor approved customers, companies, UBOs, counterparties, and payment parties after onboarding. Checklynx re-screens records against sanctions, PEP, adverse media, and watchlist changes, suppresses known false positives, routes new alerts into cases, and keeps audit evidence attached. Key points: - Customer lifecycle monitoring - Sanctions, PEP and adverse media changes - False-positive suppression - Case review and audit evidence Detail: Why onboarding checks are not enough Customer risk does not stop changing once an account is approved. A customer, UBO, counterparty, vessel, aircraft, beneficiary, or payment party may later appear on a sanctions list, become politically exposed, receive adverse media coverage, or create a new review obligation. Checklynx keeps those records under controlled review and turns meaningful changes into documented compliance work. Workflow: From customer risk change to documented decision Define who is in scope, decide what sources and cadence apply, re-screen the customer segment when policy requires it, and keep every new result connected to review, suppression, case, and audit actions. Related workflow: Connect monitoring to screening, cases, and audit evidence Ongoing monitoring is strongest when it connects to sanctions, PEP, adverse media, case management, real-time screening, and an audit trail that explains why each decision was made. Can screen or support: - Lifecycle: Monitor after onboarding - Coverage: Sanctions, PEP, adverse media, watchlists - Triage: Suppress known false positives - Evidence: Cases, outcomes, and audit trail Capabilities: - Monitor customers, UBOs, counterparties, and payment parties: Create focused customer segments for approved customers, companies, directors, UBOs, beneficiaries, counterparties, vessels, aircraft, agents, and payment parties instead of treating every monitoring run as a generic full-base exercise. - Catch sanctions, PEP, adverse media, and watchlist changes: Apply screening profiles and cadences that match the risk of each customer segment, so higher-risk groups can receive deeper or more frequent checks without overloading every review cycle. - Suppress known false positives and route new alerts: Keep analysts focused on meaningful changes by reusing resolved false-positive decisions and sending new actionable matches into case review with source context and timestamps attached. Workflow moments: - Population in scope: Approved customers, companies, UBOs, counterparties, beneficiaries, agents, vessels, aircraft, or payment parties The business knows exactly who is being monitored. - Trigger or cadence: Source update, periodic review, customer change, risk-tier change, remediation, or MLRO-selected check Monitoring happens when risk or policy requires it. - Screening coverage: Sanctions, PEP, RCA, wanted, watchlist, and adverse media profiles Controls match the customer segment and risk appetite. - New risk signal: New listing, role change, adverse article, identifier match, or related-party change Potential risk is separated from unchanged records. - False-positive suppression: Customer-level decision memory for known non-matches Repeated non-risk matches stay out of analyst queues. - Case review: Hit context, source evidence, notes, escalation, outcome, and timeline Actionable changes become owned compliance work. - Audit evidence: Population, policy, request, response, decision, reviewer, timestamp, and case history Teams can explain what changed and how they responded. FAQs: - What is AML ongoing monitoring software? AML ongoing monitoring software re-screens approved customers and related parties after onboarding so compliance teams can detect new sanctions, PEP, adverse media, watchlist, or customer-risk changes over time. - When should customers be re-screened? Common triggers include sanctions list updates, PEP role changes, new adverse media, periodic CDD reviews, customer profile changes, new UBOs or counterparties, payment-party changes, remediation exercises, and risk-tier changes. - Does ongoing monitoring replace human review? No. Monitoring identifies changes and routes potential risk into review. Your compliance policy, MLRO, or analyst team remains responsible for deciding whether a result is a true match, false positive, escalation, or enhanced due diligence case. - How does monitoring reduce repeated alert work? False-positive decisions can be retained for the customer and reused in future runs, so known non-risk matches do not keep returning as fresh analyst work. - What evidence is kept for regulators or banking partners? Monitoring records can preserve the customer segment screened, policy applied, input data, source-backed matches, suppression decisions, case notes, reviewer outcomes, timestamps, and audit history. - What is the difference between ongoing screening and transaction monitoring? Ongoing screening rechecks configured people, companies, and related parties against enabled sanctions, PEP, wanted, watchlist, and adverse-media sources. Transaction monitoring analyses activity or behaviour for unusual patterns. They may share customer context and case workflows, but they are different controls and lead to different review questions. - Can monitoring cover UBOs and related parties as well as customers? Yes, when those records and relationships are supplied to Checklynx and included in the configured population. Customers, companies, UBOs, controllers, directors, signatories, beneficiaries, counterparties, vessels, aircraft, and other relevant parties can be kept in scope according to the organisation's policy. - Is ongoing monitoring the same as a real-time screening API? No. A real-time screening API runs a check when a business event calls it, such as onboarding or a payment workflow. Ongoing monitoring keeps a defined approved population in scope over time. Organisations can use both when they need event-driven checks and continued post-onboarding review. - Can a previous false-positive decision be reused safely? A resolved non-match can be retained with the customer and candidate context so an unchanged result does not automatically become fresh analyst work. A materially changed source record, customer record, identifier, relationship, or policy can still require another review under the organisation's configured process. Operational handoff: Monitoring that connects alerts to review outcomes AML ongoing monitoring is not just another screen. The value is knowing who was monitored, why that scope was chosen, what changed, which policy applied, who reviewed the alert, and what evidence supports the final outcome. - Customer lifecycle monitoring: Monitor records after approval so onboarding is not the only moment where sanctions, PEP, adverse media, and watchlist risk is checked. - Risk-based triggers: Re-screen when source data changes, a customer profile changes, a new related party appears, or a periodic review cadence requires another check. - False-positive suppression: A resolved false positive should not return as a new alert every cycle. Suppression keeps analysts focused while preserving the decision context. - Case and audit handoff: Actionable changes become cases with ownership, notes, escalation, final disposition, and evidence that can support regulators, auditors, and banking partners. Operational handoff rows: - Customer or UBO changes: Policy-driven re-screening Compliance sees whether the change creates new exposure. - Sanctions or PEP source changes: Monitoring run Relevant changes can return for customer risk reassessment. - New adverse media signal: Case review Analysts validate relevance with source context. - Resolved non-match: Suppression Repeated false positives stay out of the queue. - Review outcome: Case timeline and audit evidence Systems and audit history stay aligned. ### AML Case Management Software for Screening and Monitoring Alerts URL: https://checklynx.com/en/solutions/case-management Turn onboarding and monitoring signals into assigned cases with hit review, evidence, escalation, timeline history, and report-ready outcomes. Key points: - Review queues and saved views - Hit review decisions - Checklist and escalation - Timeline and report artifacts Detail: Built for ongoing compliance operations Case management gives compliance teams a governed way to handle potential matches after screening. Each case carries ownership, status, priority, source context, notes, attachments, and the decision history needed to explain how the alert was handled. Workflow: From signal to case decision A screening or monitoring signal becomes owned work, analysts review the underlying hits, managers can escalate or monitor review bottlenecks, and the final outcome remains tied to the evidence that supported it. Related workflow: Connect cases to monitoring, evidence, and systems Case handling is most valuable when it is connected to the screening event that created the work, the audit trail that preserves the decision, and the systems that need to react when the case changes. Can screen or support: - Queues: Tabs, filters, saved views - Review: Hit decisions with rationale - Control: Escalation, checklist, saved views - Evidence: Timeline, attachments, reports Capabilities: - Prioritize the daily queue: Use tabs, filters, pagination, saved views, queue ownership, assignee, and review state to keep analyst work visible and manageable. - Standardize the investigation: Review one or many hits with a decision and rationale, add notes and attachments, follow required checklist items, and keep related case context in view. - Govern exceptions and outcomes: Move cases through open, in review, awaiting information, resolved, and closed states with audited transitions, escalation controls, and report artifacts. Workflow moments: - Signal raised: Onboarding, customer screening, monitoring run, or manual review trigger Potential risk becomes visible work instead of an informal task. - Case routed: Blueprint defaults, queue, assignment mode, checklist state, and escalation context The right team owns the case from the start. - Hits reviewed: Match profiles, source results, adverse outcomes, rationale, reviewer, and timestamps Analysts decide true positive, false positive, or potential match with context. - Investigation completed: Notes, events, related cases, attachments, checklist items, and optional financial context Evidence is gathered in the same place as the decision. - Outcome recorded: Resolution outcome, reason where used, resolver, timestamp, and immutable timeline The business can prove who decided what and why. - Systems updated: Webhook events Downstream teams and systems stay aligned with compliance work. FAQs: - What is AML case management software? AML case management software turns screening, monitoring, onboarding, and manually raised compliance signals into assigned investigation work. It keeps the alert context, ownership, status, review activity, evidence, rationale, escalation, and final outcome together so teams can operate and explain the process consistently. - How does case management reduce review bottlenecks? It turns potential matches into owned work with queue visibility, assignment, status, priority, hit context, notes, attachments, and escalation history. Leads can see what is aging or unassigned, while analysts start from a structured case instead of rebuilding context from searches, screenshots, and messages. - What makes a case decision easier to defend later? The case keeps the reviewed hits, source context, analyst rationale, notes, attachments, checklist progress, related cases, timestamps, and final outcome together. That creates a decision packet that QA, management, audit, or banking partners can review without asking the analyst to reconstruct the story. - Can case outcomes still update business systems? Yes. Case events can support downstream handoff when a case is created, assigned, escalated, updated, resolved, closed, or when a hit is reviewed. The important boundary is that business systems receive controlled outcomes while the compliance decision and supporting evidence remain in the governed case record. - Which alerts can become AML cases? Cases can begin from customer or counterparty screening, ongoing monitoring, onboarding exceptions, reviewed sanctions or PEP candidates, adverse-media findings, customer-risk escalation, or a manual compliance trigger. The organisation decides which signals require a case and which can follow a lighter review route. - What case statuses and ownership controls are available? Teams can use queues, assignment, priority, saved views, checklist state, escalation context, and controlled status transitions such as open, in review, awaiting information, resolved, and closed. The configured workflow should reflect the organisation's review authority and operating model. - Is a screening match the same as a case decision? No. Screening returns potential candidates that require review. A case gives an authorised reviewer the context and workflow to evaluate those candidates, gather supporting evidence, document rationale, escalate where required, and record the outcome. The candidate is an input to the decision, not the decision itself. - What remains available after a case is closed? The retained record can include the originating signal, reviewed hits, source context, notes, attachments, checklist activity, assignments, escalations, related cases, status history, reviewer rationale, outcome, timestamps, and report artifacts, subject to the customer's retention and access policies. - How are AML cases assigned to reviewers? Cases can enter a queue with priority, assignment context, status, and checklist requirements. Teams use filters and saved views to identify unassigned, active, aging, or escalated work, then apply their own operating model for analyst and senior-review ownership. - Can an AML case be escalated for second-line review? Yes. A case can retain its escalation target, status movement, transition reason where configured, checklist progress, notes, attachments, and timeline. That gives a senior reviewer the existing investigation context without requiring the first reviewer to rebuild it elsewhere. - Can supporting documents and notes be attached to a case? Yes. Notes and supporting attachments can remain connected to the case alongside reviewed hits, source context, checklist activity, related cases, rationale, and outcome. Access and retention remain subject to the customer's governance policy. - Can case information support management or audit reporting? Case records and report artifacts can bring together the case summary, reviewed hits, rationale, attachments, outcome, and action timeline. This supports internal QA, management oversight, partner reviews, and audit preparation without turning the software into the authority responsible for regulatory reporting decisions. Operational handoff: Reduce repeated review work Case management should not make analysts rebuild the same review packet every time. Checklynx keeps hit decisions, rationale, attachments, and timeline activity tied to the customer and case so future work starts from a clearer record. - Keep the queue current: Saved views, filters, tabs, and escalation visibility help leads see what is unassigned, in review, or waiting on information. - Make decisions reusable: False-positive reviews can be tied to the customer and exact screening result, reducing the chance that the same non-risk hit returns as fresh work in later checks. - Support second-line review: Escalation targets, optional transition reasons, checklist status, related cases, and full timeline history give senior reviewers the context needed for oversight. - Prepare the evidence pack: Report artifacts can draw from the case summary, reviewed hits, rationale, attachments, and action timeline instead of scattered screenshots and notes. Operational handoff rows: - Unassigned or aging work: Queue filters and queue visibility Leads can rebalance work before review bottlenecks grow. - Known false positive: Customer-scoped hit decision Analysts avoid repeating the same non-risk review. - Case needs oversight: Escalation and timeline context Senior reviewers can act without reconstructing the case. - Governance request: Report artifact and immutable audit trail Compliance can explain the decision record. ### AML Audit Trail and Decision Evidence Software URL: https://checklynx.com/en/solutions/audit-trail-and-evidence Connect screening proof, case activity, reviewer rationale, attachments, timestamps, changes, and outcomes into a reviewable AML decision history. Key points: - Actor and timestamp history - Screening proof records - Field-level case changes - Attachments and reports ### AML Screening Integrations for Existing Workflows URL: https://checklynx.com/en/solutions/integrations Connect onboarding, payment, customer, and compliance systems to AML screening through APIs, CSV imports, webhooks, case routing, and retained decision evidence. Key points: - API-triggered screening - CSV and cohort imports - Webhook outcome events - Case and evidence handoff Detail: Start simple, then automate the flows that matter Compliance integration should not require a platform migration. Connect the first operational handoff, prove the control, and move higher-volume workflows into API and webhook automation when the process is ready. Workflow: From business event to compliance outcome Checklynx sits between the systems that generate risk signals and the teams that own compliance judgment. Each integration path keeps the trigger, screening response, decision, and evidence traceable. Related workflow: Connect integrations to the rest of the AML operating model Integrations are strongest when screening, cases, monitoring, and evidence all share the same decision trail. Can screen or support: - API: Trigger checks from product events - Imports: Screen customer populations in batches - Webhooks: Send outcomes to downstream systems - Cases: Keep review decisions controlled Capabilities: - Trigger screening from business events: Call screening from onboarding, payment, customer update, or monitoring workflows so checks happen at the point of risk. - Import operational populations: Use file and cohort workflows for customer bases, remediation projects, periodic reviews, or teams that are not ready for a full API rollout. - Return decisions where work continues: Route potential matches into cases, preserve evidence, and notify downstream systems when review outcomes are ready. Workflow moments: - Business event: Onboarding, customer update, payment, monitoring cycle Screening request or import job - Ingestion path: API request, CSV import, cohort import, portal run Controlled entry point - Screening and routing: Screening profile, policy, case creation, reviewer queue Structured compliance response - Decision handoff: Case outcome, false positive, escalation, resolution note Owned review result - System update: Webhook event and report record Downstream systems aligned FAQs: - How should teams phase an AML integration? Most teams should not start by integrating every workflow. A practical rollout begins with the highest-risk or highest-volume handoff, proves the control, and then expands. CSV, cohort, and portal workflows can cover early operations while APIs and webhooks automate the paths that are stable enough to connect. - What is the commercial value beyond connectivity? The value is a clean boundary between fast business systems and controlled compliance work. Product, payment, or onboarding systems can trigger checks and receive outcome events, while Checklynx keeps the screening evidence, review rationale, case history, and audit trail under compliance control. - Can downstream systems act on compliance outcomes? Yes, when your operating model allows it. A downstream system can continue onboarding, hold a payment, request more information, or update a customer status based on a controlled outcome. The compliance decision itself remains traceable in Checklynx, with the evidence and reviewer context attached. Operational handoff: Practical integration without losing compliance control The commercial value is not just connectivity. It is a controlled handoff where business systems can move quickly while compliance keeps ownership of policy, review, and evidence. - Phased rollout: Begin with CSV, cohort, or portal workflows and move repeatable, high-volume paths into API automation over time. - Signed event delivery: Use webhook events so downstream systems can react without polling for every change. - Clear ownership boundaries: Product systems trigger the check, Checklynx screens and routes it, and compliance teams decide the outcome. - Evidence by design: Keep requests, results, case decisions, reviewer rationale, and delivery context connected for audit and governance. Operational handoff rows: - Onboarding or customer update: API-triggered screening Risk checked before the business process moves forward - Back-book or remediation batch: CSV or cohort import Large customer groups screened without manual copy-paste work - Potential match found: Case creation and reviewer assignment Compliance owns the decision and rationale - Decision completed: Webhook handoff Business systems receive the outcome they need to continue ### AML Regulatory Reporting Evidence Software URL: https://checklynx.com/en/solutions/regulatory-reporting Prepare case histories, screening evidence, reviewer rationale, attachments, timelines, and decision records for AML governance and regulatory reporting workflows. Key points: - Case summaries - Audit trail exports - Decision records - Governance evidence Detail: Bring the supporting record together before a reporting deadline Keep the screening result, case activity, reviewer rationale, attachments, and decision chronology connected so authorised teams can validate the record and prepare the required reporting artifact. Workflow: From operational activity to a reviewable reporting pack Reporting preparation starts with the retained operational record. Checklynx organises relevant screening and case evidence for internal validation and export; the organisation decides whether a filing is required and completes the regulator-specific submission. Related workflow: Connect reporting preparation to cases, audit evidence, and integrations A reporting record is strongest when the underlying screening event, human review, chronology, and downstream handoff remain connected. Can screen or support: - Timeline: Preserve review history - Evidence: Keep source-backed context - Governance: Support oversight questions - Exports: Prepare reporting packs Capabilities: - Make reporting traceable: Connect screening runs, case actions, notes, attachments, and decisions into a timeline that can be reviewed later. - Reduce manual evidence collection: Avoid rebuilding reports from screenshots, spreadsheets, and disconnected analyst notes. - Support governance reviews: Help MLRO, audit, and management teams understand how alerts were handled and why decisions were made. Workflow moments: - Collect activity: Screening, cases, notes, attachments, decisions Reporting inputs. - Structure evidence: Timeline, source context, ownership Governance view. - Review internally: MLRO, audit, management, compliance QA Validated record. - Respond externally: Regulator questions, partner reviews, audits Defensible pack. FAQs: - What does AML regulatory reporting evidence software prepare? It organises the supporting operational record: customer or counterparty context, screening results, source evidence, case notes, attachments, reviewer actions, rationale, decisions, and timestamps. The organisation decides which elements belong in a particular internal or external report. - Does Checklynx file SARs, STRs, or other regulatory reports? No. Checklynx does not determine whether a filing is legally required and does not submit SARs, STRs, or regulator-specific forms. It helps authorised teams prepare and review the evidence that supports their own reporting process. - How is regulatory reporting different from an audit trail? The audit trail records who did what, when, and against which object. Reporting preparation selects the relevant case, screening, decision, and supporting evidence for a defined governance or external reporting purpose. The reporting pack can rely on the audit trail without being identical to it. - Can reporting evidence be exported to another system? Checklynx can organise report artifacts and support controlled downstream handoffs through the available integration workflow. The destination format, filing procedure, access controls, and final submission remain governed by the organisation and the applicable jurisdiction. - Does every screening alert become a regulatory report? No. A screening result is a candidate for review, not an automatic reporting conclusion. Authorised people assess the facts, apply policy and legal requirements, document the outcome, and decide whether any internal escalation or external filing is necessary. Operational handoff: Prepare the evidence without automating the legal reporting decision Checklynx helps teams organise the record behind an alert or case. It does not determine whether a SAR, STR, or other filing is legally required, submit reports to a regulator, or replace jurisdiction-specific forms and procedures. - Evidence assembled: Bring the customer or counterparty context, screening sources, case notes, attachments, reviewer actions, and outcome into one chronology. - Internal validation: Give MLRO, quality-assurance, audit, or management reviewers a consistent record to inspect before an authorised next step. - Controlled export: Prepare the relevant case or decision record for the organisation's reporting process without treating every screening alert as reportable activity. Operational handoff rows: - Potential issue reviewed: Screening result, source context, case activity, and rationale The operational decision is documented. - Reporting assessment: Complete retained record and internal policy An authorised person decides whether reporting is required. - External process: Validated facts and organisation-approved artifact The organisation completes its jurisdiction-specific filing or response. ## Industries ### AML Screening Software for Remittance and Money Transfer Companies URL: https://checklynx.com/en/industries/money-movement-remittance Screen senders, recipients, agents, counterparties, and cross-border transfers across sanctions, PEP, adverse media, and watchlist data with fast checks and audit-ready evidence. Key points: - Sender and recipient screening - Agent and counterparty review - Transfer and payout checks - Audit-ready case evidence Detail: Built for regulated transfer and payout workflows Remittance, FX, wallet, PSP, and payout providers need AML checks that keep pace with transfer speed. Checklynx gives teams a practical way to screen the people, entities, identifiers, and counterparties involved in each movement of funds. Workflow: From transfer signal to documented decision A sender, recipient, agent, or transfer signal becomes owned work, analysts review the underlying match, and the outcome stays tied to the evidence that supported it. Related workflow: Connect remittance screening to API checks, monitoring, and cases Money movement screening is strongest when real-time checks, batch rescreening, ongoing monitoring, and case evidence work from the same decision record. Can screen or support: - Senders: Customer and originator checks - Recipients: Beneficiary and payout review - Agents: Partner and location screening - Evidence: Cases, rationale, audit trail Capabilities: - Screen both sides of the transfer: Check senders, recipients, beneficiaries, payout recipients, agents, business customers, directors, UBOs, and payment counterparties. - Use identifiers to reduce ambiguity: Go beyond names with IBANs, tax IDs, passport-style identifiers, payment references, country context, and crypto wallet addresses where relevant. - Keep review evidence in one place: Preserve match sources, analyst rationale, notes, escalation history, decisions, and timestamps for audit, partner, and internal review. Workflow moments: - Onboarding: Sender, recipient, agent, business customer, director, or UBO profile Risk is checked before approval or activation. - Transfer created: Counterparty, corridor, destination market, IBAN, reference, or wallet address Potential exposure is reviewed before funds move. - Hit reviewed: Sanctions, PEP, adverse media, criminal, or watchlist match context Analysts decide true positive, false positive, or escalation with evidence. - Monitoring update: New sanctions listing, PEP change, adverse media event, or watchlist update Existing customers and agents stay visible after onboarding. - Outcome recorded: Decision, rationale, reviewer, timestamp, attachments, and audit trail The business can explain who decided what and why. FAQs: - What should remittance companies screen? Remittance teams commonly screen senders, recipients, beneficiaries, payout recipients, agents, business customers, directors, UBOs, payment counterparties, identifiers, and transfer context. - Should both sender and recipient be screened? In many transfer workflows, screening both sides helps identify sanctions, PEP, adverse media, watchlist, and counterparty exposure before funds are released. - Can screening happen before a transfer is released? Yes. Checklynx can support API-based checks during onboarding, transfer creation, payout review, or manual escalation. - Does Checklynx replace a full AML program? No. Checklynx supports screening, monitoring, case review, and audit evidence workflows. Legal obligations and broader AML program design depend on the business model and jurisdiction. Operational handoff: Reduce repeated screening work across transfer operations Screening should not force analysts to rebuild the same review packet every time a customer sends money. Checklynx keeps decisions, source context, and monitoring history connected to the profile and case. - Sender or recipient hit: Review sanctions, PEP, adverse media, and watchlist context with profile details, identifiers, corridor context, and transfer timing. - Agent or partner review: Batch screen agent networks, payout partners, business customers, directors, and UBOs before or after activation. - Known false positive: Reuse prior decisions where appropriate so the same non-risk hit does not create repeated manual work. - Audit or bank request: Export source-backed evidence, decisions, notes, escalation events, and review history when partners or auditors ask for proof. Operational handoff rows: - Potential sanctions hit: Case review with source context Analysts can decide before payout or release. - New or updated agent: Batch or API screening Partner risk is reviewed before exposure grows. - Repeated non-risk match: Customer-scoped decision memory The same false positive does not keep returning as new work. - Governance request: Case evidence and immutable audit trail Compliance can explain the decision record. ### AML and Sanctions Screening Software for Payment Companies URL: https://checklynx.com/en/industries/payments Screen customers, merchants, counterparties, beneficiaries, payouts, and payment events across sanctions, PEP, adverse media, and watchlist data before exposure is created. Key points: - Payment and payout screening - Merchant and counterparty checks - Sanctions and PEP review - Audit-ready case evidence Detail: Built for payment, payout, merchant, and counterparty workflows Payment companies need to move value quickly while managing AML, sanctions, PEP, adverse media, merchant, counterparty, and payout exposure. Checklynx helps teams screen parties and payment context at the right moment, then preserve evidence when review is needed. Workflow: From payment signal to documented decision A payment initiation, merchant onboarding event, payout trigger, beneficiary update, counterparty match, or monitoring update becomes owned review work with source context and decision evidence attached. Related workflow: Connect payment screening to API checks, monitoring, and cases Payment screening is strongest when real-time API checks, transaction screening, merchant review, ongoing monitoring, and audit evidence share the same decision trail. Can screen or support: - Payments: Transaction and payout checks - Merchants: Customer and seller review - Counterparties: Beneficiary screening - Evidence: Cases, rationale, audit trail Capabilities: - Screen parties before value moves: Check customers, merchants, senders, receivers, beneficiaries, payout recipients, counterparties, and payment references before approval, release, or settlement. - Review merchants and business customers: Screen merchants, platforms, directors, UBOs, vendors, agents, and business identifiers during onboarding, refresh, or risk-triggered review. - Keep payment decisions audit-ready: Preserve match sources, analyst rationale, notes, escalation history, decisions, and timestamps for compliance, partner, bank, and audit questions. Workflow moments: - Merchant onboarding: Merchant, company, director, UBO, country, identifier, sanctions, PEP, adverse media, or watchlist context Risk is checked before approval or activation. - Payment initiated: Sender, receiver, beneficiary, counterparty, payment reference, IBAN, country, or transaction context Potential exposure is reviewed before value moves. - Payout trigger: Merchant, seller, payout recipient, beneficiary, bank detail, payment reference, or restricted geography Payout risk can be reviewed before funds are released. - Monitoring update: New sanctions listing, PEP change, adverse media event, or watchlist update Approved customers and merchants stay visible after onboarding. - Outcome recorded: Decision, rationale, reviewer, timestamp, attachments, and audit trail The business can explain who decided what and why. FAQs: - What should payment companies screen? Payment teams commonly screen customers, merchants, senders, receivers, beneficiaries, payout recipients, directors, UBOs, counterparties, payment references, transaction context. - When should payments be screened? Screening can happen during merchant onboarding, customer approval, payment initiation, transfer creation, payout release, beneficiary setup, periodic review, and ongoing monitoring updates. - Can screening happen before payment release? Yes. Checklynx supports API-based checks, transaction screening, case review, reusable decisions, and evidence capture so teams can review matches before value moves. - Does Checklynx replace a full AML program? No. Checklynx supports screening, monitoring, case review, and audit evidence workflows. Legal obligations, policies, and final compliance decisions remain with the payment company and depend on jurisdiction and business model. Operational handoff: Reduce repeated screening work across payment operations Payment screening should not make analysts rebuild the same evidence packet every time a merchant is paid, a counterparty is reviewed, or a payment is held. Checklynx keeps decisions, source context, and monitoring history connected to the profile and case. - Payment or payout hit: Review sanctions, PEP, adverse media, and watchlist context with party details, identifiers, payment references, and transaction timing. - Merchant review: Screen merchants, directors, UBOs, platform customers, agents, vendors, and business identifiers before activation or periodic refresh. - Counterparty review: Check beneficiaries, senders, receivers, payout recipients, payment details, and restricted geographies before release. - Known false positive: Reuse prior decisions where appropriate so the same non-risk hit does not create repeated manual work. Operational handoff rows: - Potential sanctions hit: Case review with source context Analysts can decide before payment, payout, or merchant activation. - Payout trigger: Screening and case handoff Operations can hold, review, or clear activity with evidence. - Merchant refresh: Batch or monitoring run Merchant and counterparty risk stays current. - Bank or audit request: Case evidence and immutable audit trail Compliance can explain the decision record. ### AML and Sanctions Screening Software for Fintech Companies URL: https://checklynx.com/en/industries/fintech Screen customers, businesses, beneficiaries, counterparties, payments, and product events across sanctions, PEP, adverse media, and watchlist data with API-first workflows and audit-ready evidence. Key points: - Customer and KYB screening - Payment and counterparty checks - Sanctions and PEP review - API-first audit evidence Detail: Built for fast-moving onboarding, payments, and product risk Fintech teams need screening that fits product velocity without leaving compliance teams to manage disconnected alerts. Checklynx helps screen people, companies, identifiers, payment context, and counterparties at onboarding, transaction, review, and monitoring moments. Workflow: From product event to documented decision A signup, KYB application, payment trigger, beneficiary change, partner review, monitoring hit, or manual escalation becomes structured review work with source context and decision evidence attached. Related workflow: Connect fintech screening to API checks, monitoring, and cases Fintech screening works best when onboarding checks, transaction screening, ongoing monitoring, case review, and audit evidence share the same decision record. Can screen or support: - Customers: KYC and KYB screening - Payments: Transaction and payout checks - Counterparties: Beneficiary and partner review - Evidence: Cases, rationale, audit trail Capabilities: - Screen during onboarding and activation: Check customers, business accounts, merchants, directors, UBOs, partners, agents, and identifiers before access, activation, or limit increases. - Review payments and counterparties: Screen beneficiaries, payout recipients, payment references, beneficiary or counterparty identifiers, counterparties, countries, and transaction context when risk appears. - Keep product decisions explainable: Preserve source evidence, analyst rationale, notes, escalation history, decisions, timestamps, and case activity for compliance, partners, and audits. Workflow moments: - Customer signup: Individual, company, director, UBO, tax ID, passport-style identifier, sanctions, PEP, adverse media, or watchlist context Risk is checked before account activation or product access. - Business onboarding: Merchant, platform customer, vendor, agent, partner, beneficial owner, company identifier, and country context KYB and counterparty exposure becomes visible before approval. - Payment or payout event: Beneficiary, payout recipient, payment reference, sender, receiver, country, and transaction context Teams can review potential exposure before value moves. - Monitoring update: New sanctions listing, PEP change, adverse media event, or watchlist update Previously approved users and businesses stay visible after onboarding. - Decision recorded: Case owner, rationale, source evidence, timestamps, escalation, and final outcome The business can explain who decided what and why. FAQs: - What should fintech companies screen? Fintech teams commonly screen customers, business accounts, merchants, directors, UBOs, beneficiaries, payout recipients, vendors, agents, partners, counterparties, identifiers, transaction context. - When should fintech screening happen? Screening can happen during signup, KYB onboarding, account activation, limit changes, payment initiation, payout release, beneficiary setup, periodic review, and ongoing monitoring updates. - Can Checklynx support API-first fintech onboarding? Yes. Checklynx supports real-time API checks, transaction screening, batch screening, ongoing monitoring, case management, and audit evidence for product-led screening workflows. - Does every fintech have the same AML obligations? No. AML obligations depend on jurisdiction, licensing, product model, customer type, and whether regulated financial activity is involved. Checklynx supports screening and evidence workflows, but legal obligations remain business-specific. Operational handoff: Reduce manual review load across fintech operations Fintech screening should support fast products without turning every alert into a manual rebuild. Checklynx keeps screening results, source context, case notes, and monitoring history tied to the profile and event. - Onboarding hit: Review sanctions, PEP, adverse media, and watchlist context with customer, company, identifier, and product details in one place. - Payment review: Screen beneficiaries, payout recipients, payment references, counterparties, and transaction context before release. - Business account review: Check merchants, companies, directors, UBOs, vendors, agents, and partners during onboarding, refresh, or escalation. - Known false positive: Reuse prior decisions where appropriate so the same non-risk hit does not create repeated manual work. Operational handoff rows: - Potential sanctions hit: Case review with source context Analysts can decide before account activation, payment release, or partner approval. - High-risk payment: Screening and case handoff Operations can hold, review, or clear activity with evidence. - KYB refresh: Batch or monitoring run Business customer and counterparty risk stays current. - Partner or audit request: Case evidence and immutable audit trail Compliance can explain the decision record. ### AML and Sanctions Screening for Crypto Platforms and VASPs URL: https://checklynx.com/en/industries/crypto-vasp-aml-screening Screen customers, companies, transfer parties, and supplied wallet addresses against sanctions identifiers. Keep review evidence connected. Key points: - Customer sanctions and PEP screening - Transaction-party screening - Wallet-address sanctions checks - Review and documentation Detail: Bring the parties, checks and review context together A new account, corporate customer or withdrawal can introduce different people, entities and identifiers. Checklynx provides a screening layer for those inputs, while your team controls how results affect onboarding and transfers. Workflow: Choose a screening checkpoint for each business event Define which subjects enter scope, which information your platform supplies and who responds to a finding. A customer check and a later transfer check may involve different parties and addresses. Related workflow: Choose the implementation and evidence model that fits your team Use the portal for analyst-led screening, customer-file workflows for suitable batch reviews, or APIs for repeatable application events. Confirm the supported input and evidence path for each use case before implementation. Can screen or support: - Onboarding: Customer and entity sanctions/PEP checks - Transfers: Supplied parties and wallet identifiers - Review: Results with source context - Evidence: Retrievable transaction-screening runs Capabilities: - Screen the customer relationship: Check customers, companies and already-identified related parties against sanctions and PEP data where your policy requires it. Use adverse-media checks as a separate source of risk information. - Connect checks to the transfer: Submit the relevant transaction parties and supported wallet-address inputs together. Retain a run reference and per-party results so reviewers can see which information was screened. - Spend less time assembling documentation: Keep transaction-screening evidence retrievable and connect actionable results to case review where applicable. Reduce repeated copying of screening context when preparing reviews and explaining decisions. Workflow moments: - Customer onboarding: Person or company information and relevant identifiers Sanctions and PEP screening with results for review. - Corporate relationship review: Already-identified owners, controllers or other parties required by policy Screening of the supplied parties; ownership discovery and analysis remain separate. - Deposit, withdrawal or transfer: Relevant parties, client transaction reference and supported wallet-address inputs A transaction-screening run with per-party results and retrievable evidence. - Customer review after onboarding: Maintained customer records and dashboard-configured monitoring Re-screening of customer records under the configured workflow. FAQs: - Does Checklynx provide a complete crypto AML platform? Checklynx provides sanctions and PEP screening, a separate adverse-media workflow, transaction-party screening and review/evidence capabilities. Identity verification, blockchain intelligence, Travel Rule information exchange and behavioural transaction monitoring require their own controls and systems. - What does a wallet-address sanctions check cover? For the supported wallet_address payment instrument, Checklynx screens the supplied address when sanctions identity screening is enabled in the selected profile. It does not establish ownership, trace funds or calculate indirect on-chain exposure. A no-candidate result is not confirmation that the wallet or transfer is free of sanctions risk. - Can we screen beneficial owners and other related parties? You can screen the people and entities your team has already identified and supplied for review. Deciding which parties must be checked, establishing the ownership structure and assessing sanctions ownership or control remain separate responsibilities. - How do API checks connect to documentation? The Transaction Screening API creates a retrievable screening run and may link actionable results to a case. Direct sanctions/PEP and adverse-media checks do not create customer or case records, so your application must retain its own review and decision evidence for those workflows. Use the current developer documentation to select the appropriate model. - Can customer screening continue after onboarding? Checklynx customer records can be used in dashboard-configured ongoing monitoring. Monitoring configuration and execution are not currently exposed through the public API. This customer re-screening is distinct from on-chain or behavioural monitoring. Operational handoff: Fit screening into the rest of your crypto controls Your platform and compliance team retain the onboarding and transfer decision. Checklynx supplies screening results and review context; it does not decide whether funds must be held, released, rejected, blocked or reported. - Wallet-address sanctions checks: The Transaction Screening API supports a supplied wallet_address instrument. Its address is checked when the selected profile enables sanctions identity screening. This is a check against supported sanctions identifiers, not wallet ownership verification or an on-chain risk score. - Separate controls, connected context: Use your identity-verification, blockchain-analysis and Travel Rule systems for their respective tasks. Checklynx does not provide chain tracing, wallet attribution or clustering, indirect-exposure analysis, behavioural crypto monitoring or Travel Rule message exchange. Operational handoff rows: - A transfer requires review: Use the returned run and case references where available Keep the screening evidence connected to the authorised decision. - Screening opens a case: Receive supported signed case-opened webhooks Notify your workflow that review work exists; do not treat the event as a final decision. - A customer needs re-screening: Maintain the record and configure monitoring in the dashboard Review the customer again without implying continuous observation of blockchain activity. ### AML and Sanctions Screening Software for Embedded Finance URL: https://checklynx.com/en/industries/embedded-finance Screen customers, partners, accounts, beneficiaries, transactions, and counterparties inside embedded financial products with API-first checks, ongoing monitoring, and audit-ready evidence. Key points: - API-first customer screening - Partner and program review - Transaction and beneficiary checks - Audit-ready case evidence Detail: Built for financial products delivered through platforms and partners Embedded finance teams need screening that fits product flows while giving compliance, operations, and partner teams a clear decision record. Checklynx helps screen customers, businesses, partners, beneficiaries, identifiers, transactions, and counterparties at the moments risk enters the product. Workflow: From embedded product event to documented decision A platform signup, partner onboarding event, customer activation, account update, transaction trigger, beneficiary change, monitoring hit, or manual escalation becomes structured review work with source context and decision evidence attached. Related workflow: Connect embedded screening to API checks, monitoring, and cases Embedded finance screening works best when real-time API checks, transaction screening, partner review, ongoing monitoring, case management, and audit evidence share one decision trail. Can screen or support: - Customers: Signup and account checks - Partners: Program and platform review - Transactions: Payment and beneficiary screening - Evidence: Cases, rationale, audit trail Capabilities: - Screen inside product flows: Run checks during signup, account activation, partner onboarding, beneficiary setup, limit changes, and transaction events through API-first workflows. - Review partners and counterparties: Screen platforms, program partners, merchants, customers, directors, UBOs, vendors, beneficiaries, payout recipients, and counterparties. - Keep partner decisions explainable: Preserve source evidence, analyst rationale, notes, escalation history, decisions, timestamps, and case activity for internal, sponsor, bank, and audit questions. Workflow moments: - Partner onboarding: Platform, program partner, merchant, company, director, UBO, country, sanctions, PEP, adverse media, or watchlist context Partner exposure is checked before launch or activation. - Customer activation: Individual, business, identifier, account party, country, product context, and watchlist result Risk is checked before access to financial features. - Transaction or payout event: Sender, receiver, beneficiary, payout recipient, payment reference, counterparty, and country context Potential exposure can be reviewed before value moves. - Monitoring update: New sanctions listing, PEP change, adverse media event, or watchlist update Approved customers, partners, and counterparties stay visible after onboarding. - Decision recorded: Case owner, rationale, source evidence, timestamps, escalation, and final outcome The business can explain who decided what and why. FAQs: - What should embedded finance companies screen? Embedded finance teams commonly screen customers, business accounts, platforms, merchants, program partners, directors, UBOs, vendors, beneficiaries, payout recipients, counterparties, identifiers, transaction context. - When should embedded finance screening happen? Screening can happen during partner onboarding, customer signup, account activation, beneficiary setup, payment initiation, payout release, periodic review, manual escalation, and ongoing monitoring updates. - Can screening be embedded into product workflows? Yes. Checklynx supports real-time API checks, transaction screening, ongoing monitoring, case management, and audit evidence for product-led onboarding and financial workflows. - Does every embedded finance company have the same AML obligations? No. Obligations depend on jurisdiction, licensing, sponsor-bank model, regulated activities, and product design. Checklynx supports screening and evidence workflows, while legal obligations remain business-specific. Operational handoff: Keep embedded finance review work connected to the product Embedded finance screening should support fast platform experiences while giving compliance teams usable evidence. Checklynx keeps API checks, transaction context, monitoring hits, case notes, and partner decisions tied to the profile and event. - Product signup hit: Review sanctions, PEP, adverse media, and watchlist context with customer, business, identifier, and product details. - Partner review: Screen platforms, merchants, program partners, vendors, directors, UBOs, and country exposure before activation or refresh. - Transaction review: Check beneficiaries, payout recipients, payment references, counterparties, and transaction context before release. - Known false positive: Reuse prior decisions where appropriate so the same non-risk hit does not create repeated manual work. Operational handoff rows: - Potential sanctions hit: Case review with source context Analysts can decide before account activation, partner approval, or payment release. - Partner refresh: Batch or monitoring run Program and platform risk stays current after onboarding. - Beneficiary update: Counterparty screening Product teams can review exposure before value moves. - Sponsor or audit request: Case evidence and immutable audit trail Compliance can explain the decision record. ### Sanctions, PEP and AML Screening Software for Insurance URL: https://checklynx.com/en/industries/insurance-insurtech Support sanctions and PEP screening across policyholder, beneficiary, claim and payout workflows with API, batch, monitoring, case review and screening evidence. Key points: - Policyholder screening - Beneficiary and claimant checks - Claims payout review - Broker and vendor screening Detail: Place screening at the right insurance lifecycle events An applicant, policyholder, insured person, beneficiary, premium payer, claimant, payee or intermediary can become relevant at a different point in the policy or claim lifecycle. The appropriate population, source and trigger depend on the jurisdiction, insurance product, facts and the insurer's approved control design. Workflow: Which party becomes relevant at which event? This is not a universal regulatory checklist. It shows how supplied insurance-party data can enter sanctions or PEP screening while keeping identity, customer-risk, claim and legal decisions outside the screening result. Related workflow: Connect insurance screening to monitoring, cases, and evidence Insurance screening is strongest when policyholder checks, claims payout review, broker screening, ongoing monitoring, and audit evidence share the same decision trail. Can screen or support: - Applicants: Policyholder checks - Claims: Claimant and payout review - Brokers: Intermediary screening - Evidence: Cases, rationale, audit trail Capabilities: - Keep sanctions and PEP outcomes separate: A sanctions candidate and a PEP candidate answer different questions. Neither result alone confirms identity, determines customer risk, or decides whether a policy or payment can proceed. - Give beneficiaries and payouts their own trigger: A beneficiary, claimant or payee may only become known later. An approved workflow can screen supplied identity and payment-party data when the role or payout instruction is created or changed. - Adapt controls to product and jurisdiction: Life, investment-related, general and intermediated insurance do not share one worldwide AML perimeter. Screening scope and timing should follow the applicable rules, exposure and internal policy. Workflow moments: - Application or policy activation: Applicant, policyholder, insured person, company and supplied owner/controller data; applicable sanctions sources and any separate PEP determination Identity verification, underwriting, customer-risk treatment and policy acceptance - Beneficiary added or changed: Beneficiary and supplied beneficial-owner data; sanctions screening and, where the framework calls for it, a separate PEP determination Beneficiary eligibility, PEP-risk measures and whether the change may proceed - Premium or funding instruction: Premium payer, funder or payment party; applicable sanctions sources and any separately configured PEP question Source-of-funds verification and acceptance of the payment - Claim notification or assessment: Claimant and newly introduced claim parties; sanctions and PEP results remain separately labelled where both are run Fraud detection, claim validity, coverage and settlement amount - Payout instruction: Beneficiary, claimant, payee, recipient and relevant payment parties; applicable sanctions sources and any separate PEP determination Final identity, sanctions applicability, licence/reporting duties and release of funds - Intermediary or counterparty review: Broker, agent, distributor, service provider, reinsurer or other relevant counterparty; source categories follow the approved control Contract approval, reliance decisions and wider third-party due diligence - Data, source or policy change: Approved populations affected by a sanctions-source, PEP-data or policy trigger; each result retains its source category Revised legal perimeter, remediation and final relationship decisions FAQs: - When should insurers screen policyholders and beneficiaries? There is no universal schedule. Depending on the applicable rules, insurance product, facts and approved control design, screening may be triggered by application, policy activation, a beneficiary or ownership change, a claim or payout instruction, a source-data change, or a defined portfolio review. - Should claims payouts be screened? A payout can introduce a beneficiary, claimant, payee or other payment party that was not relevant earlier. Whether and how that party should be screened depends on the applicable jurisdiction, product and control framework. Screening supplies a candidate result; it does not decide claim validity or authorise payment. - How does PEP screening apply to insurance? PEP screening can identify a candidate involving a policyholder, beneficiary or relevant beneficial owner where the applicable framework calls for that determination. PEP status is not sanctions status, evidence of criminality or an automatic reason to reject a customer; the insurer applies the required risk-based measures separately. - Does sanctions or PEP screening verify identity or beneficial ownership? No. Checklynx compares supplied identity and relationship data with supported sources and returns candidates for review. The insurer remains responsible for identity verification, obtaining and verifying ownership information, determining which people and sources are in scope, and making final compliance and business decisions. - Does Checklynx replace an insurer's AML or sanctions program? No. Checklynx supports screening of supplied parties, re-screening, case review and evidence. It does not perform underwriting, policy administration, claims adjudication, fraud detection, source-of-funds verification, behavioural transaction monitoring or final legal and payment decisions. Operational handoff: Reduce repeated screening work across policy and claims operations Use API checks for approved event-driven workflows, batch screening for supplied portfolios, and ongoing re-screening for relevant data changes. Candidate results still require review under the insurer's policy; the system does not adjudicate a claim or make the legal decision. - Policyholder or applicant hit: Review the candidate with supplied identifiers and source context. A name match is not confirmation that the person is the listed target. - Claim or payout review: Screen configured claimants, beneficiaries, payees and payment parties, then keep claim validity and payment authorisation outside the screening outcome. - Broker and intermediary review: Use portal or batch workflows for supplied brokers, agents, distributors and other relevant counterparties under the insurer's approved population rules. - Known false positive: Reuse a previously reviewed non-match only when the relevant identity data, source record, relationship context and approved reuse conditions remain valid; otherwise route it for renewed review. Operational handoff rows: - Application or change event: Real-time API or Screening Portal Candidate and source context enter the approved review route. - Portfolio review: CSV batch screening A supplied population is checked under one controlled configuration. - Relevant source-data change: Ongoing re-screening New candidates are routed with earlier review context where available. - Possible match: Case management and screening evidence An authorised reviewer records rationale, escalation and outcome. ### AML Screening Software for iGaming and Gambling Operators URL: https://checklynx.com/en/industries/igaming-gambling Screen supplied players and payout parties against configured sanctions, PEP, adverse-media, and watchlist sources, with controlled review and audit-ready evidence. Key points: - Player onboarding screening - Withdrawal and payout review - PEP and sanctions checks - Audit-ready case evidence Detail: Built for fast onboarding and controlled player review Gaming operators need AML, sanctions, PEP, adverse media, and watchlist screening without turning every legitimate player interaction into a manual compliance delay. Checklynx supports player onboarding, withdrawal review, high-risk player checks, monitoring, and case evidence from one workflow. Workflow: From player signal to documented decision A player signup, withdrawal, PEP hit, sanctions match, or monitoring update becomes owned review work, with source context and decision evidence kept alongside the case. Related workflow: Connect iGaming screening to API checks, monitoring, and cases iGaming screening is strongest when onboarding checks, withdrawal review, ongoing monitoring, case management, and audit evidence all share the same decision record. Can screen or support: - Players: Signup and profile checks - Withdrawals: Payout review before release - Monitoring: Ongoing player risk changes - Evidence: Cases, rationale, audit trail Capabilities: - Screen players before risk enters the platform: Check players at signup, account review, high-risk trigger, source-of-funds escalation, or withdrawal review against sanctions, PEP, adverse media, and watchlist data. - Keep withdrawals moving with controlled review: Use screening and case context to review high-value withdrawals, new beneficiaries, PEP exposure, sanctions matches, and repeated false positives before payout release. - Document decisions for audits and internal review: Preserve match sources, analyst rationale, notes, escalation history, decisions, and timestamps for compliance, MLRO, partner, and audit questions. Workflow moments: - Player signup: Name, date of birth, country, identifiers, sanctions, PEP, adverse media, or watchlist context Risk is checked before approval or account activation. - Withdrawal requested: Payout recipient, payment details, high-value activity, PEP exposure, or sanctions context Potential exposure is reviewed before funds leave the platform. - High-risk trigger: Large deposits, unusual play, new beneficiary, geography change, or source-of-funds escalation Compliance receives a focused review task instead of scattered context. - Monitoring update: New sanctions listing, PEP change, adverse media event, or watchlist update Approved players stay visible after signup. - Outcome recorded: Decision, rationale, reviewer, timestamp, attachments, and audit trail The operator can explain who decided what and why. FAQs: - What should iGaming operators screen? Operators commonly screen players, payout recipients, beneficiaries, payment identifiers, high-risk events, PEP exposure, sanctions matches, adverse media, and watchlist records. - When should gambling operators screen players? Screening can happen at signup, before withdrawal release, during high-risk player review, on source-of-funds escalation, during periodic review, and through ongoing monitoring after approval. - Can screening work without delaying every withdrawal? Yes. Checklynx supports API-based checks, reusable decisions, case review, and evidence capture so teams can focus manual review on matches and higher-risk events. - Does Checklynx replace a gambling operator's AML program? No. Checklynx supports screening, monitoring, case review, and audit evidence workflows. Legal obligations, policies, and final compliance decisions remain with the operator and depend on jurisdiction. Operational handoff: Reduce repeated screening work across player operations Screening should not make analysts rebuild the same review packet every time a player deposits, withdraws, or triggers a risk review. Checklynx keeps decisions, source context, and monitoring history connected to the player and case. - Player or beneficiary hit: Review sanctions, PEP, adverse media, and watchlist context with profile details, identifiers, payment details, and player history. - Withdrawal review: Screen high-value withdrawals, new payout recipients, unusual activity, and escalated player profiles before release. - Known false positive: Reuse prior decisions where appropriate so the same non-risk hit does not create repeated manual work. - Audit or MLRO request: Export source-backed evidence, decisions, notes, escalation events, and review history when governance teams ask for proof. Operational handoff rows: - Potential sanctions hit: Case review with source context Analysts can decide before account approval or payout. - Withdrawal escalation: Screening and case handoff Funds can be held, reviewed, or cleared with evidence. - Repeated non-risk match: Player-scoped decision memory The same false positive does not keep returning as new work. - Governance request: Case evidence and immutable audit trail Compliance can explain the decision record. ### Marketplace Sanctions Screening Software for Sellers and Payouts URL: https://checklynx.com/en/industries/marketplaces Screen supplied sellers, merchants, payout recipients, suppliers, and marketplace counterparties against configured sanctions, adverse-media, and watchlist sources. Key points: - Seller and merchant onboarding - Payout recipient screening - Supplier and counterparty review - Case evidence and audit trail Detail: Built for seller onboarding, payout, and counterparty review Marketplaces need to onboard sellers, move payouts, review high-value activity, and manage supplier or counterparty exposure without adding unnecessary friction to legitimate commerce. Checklynx helps teams screen the parties around marketplace transactions and preserve evidence when a review is needed. Workflow: From marketplace signal to documented decision A seller onboarding event, buyer review, payout trigger, supplier check, refund escalation, or monitoring update becomes owned review work with match context and decision evidence attached. Related workflow: Connect marketplace screening to API checks, monitoring, and cases Marketplace screening is strongest when seller checks, payout review, batch screening, ongoing monitoring, and audit evidence share the same decision trail. Can screen or support: - Sellers: Merchant onboarding checks - Payouts: Recipient and beneficiary review - Buyers: High-value order screening - Evidence: Cases, rationale, audit trail Capabilities: - Screen sellers before activation: Check merchants, stores, companies, directors, UBOs, sellers, payout recipients, and business identifiers before seller approval or payout enablement. - Review buyers, orders, refunds, and payouts: Screen high-value buyers, unusual order activity, refund recipients, beneficiaries, payout details, payment references, and marketplace counterparties. - Keep supplier and partner risk visible: Screen suppliers, vendors, fulfilment partners, agencies, affiliates, and business counterparties through API, portal, batch, or monitoring workflows. Workflow moments: - Seller onboarding: Merchant, store, company, director, UBO, payout recipient, country, identifier, sanctions, or watchlist context Risk is checked before seller approval or payout activation. - Order or buyer review: Buyer, account holder, order value, destination, payment detail, refund signal, or counterparty Potential exposure is reviewed before fulfilment, refund, or release. - Payout trigger: Seller, beneficiary, payout recipient, bank detail, payment reference, or restricted geography Marketplace payouts can be reviewed before funds move. - Supplier or partner review: Vendor, supplier, fulfilment partner, affiliate, agency, or business counterparty Third-party risk stays visible across the marketplace network. - Outcome recorded: Decision, rationale, reviewer, timestamp, attachments, and audit trail The business can explain who decided what and why. FAQs: - What should marketplaces screen? Marketplaces can screen sellers, merchants, buyers, payout recipients, beneficiaries, vendors, suppliers, fulfilment partners, directors, UBOs, payment details, destinations, and counterparties. - Should marketplace payouts be screened? Payout screening can help identify sanctions, restricted-party, adverse media, watchlist, and counterparty exposure before funds are released to sellers, beneficiaries, or payout partners. - How can screening work without slowing marketplace growth? Checklynx supports API checks, batch screening, reusable decisions, ongoing monitoring, and case workflows so teams can apply screening at the right risk points instead of manually reviewing every transaction. - Does Checklynx claim every marketplace has AML obligations? No. Marketplace pages should focus on sanctions, counterparty, supplier, payout, restricted-party, and reputational-risk exposure. AML obligations depend on the marketplace model, geography, payments flow, and regulated activities involved. Operational handoff: Reduce repeated screening work across marketplace operations Marketplace screening should not make teams rebuild the same evidence packet every time a seller is paid, a buyer is reviewed, or a vendor is refreshed. Checklynx keeps decisions, source context, and monitoring history connected to the profile and case. - Seller or merchant hit: Review sanctions, adverse media, and watchlist context with company details, payout data, ownership context, and seller status. - Buyer or order review: Screen high-value orders, unusual refunds, destination context, payment details, and marketplace counterparties before fulfilment or release. - Payout recipient review: Check beneficiaries, sellers, payment references, bank details, and restricted geographies before marketplace payouts move. - Known false positive: Reuse prior decisions where appropriate so the same non-risk hit does not create repeated manual work. Operational handoff rows: - Potential sanctions hit: Case review with source context Analysts can decide before seller approval, fulfilment, or payout. - Payout trigger: Screening and case handoff Operations can hold, review, or clear activity with evidence. - Seller refresh: Batch or monitoring run Seller and counterparty risk stays current. - Governance request: Case evidence and immutable audit trail Operations, legal, and compliance can explain the decision record. ### E-commerce Sanctions Screening Software for Sellers and Suppliers URL: https://checklynx.com/en/industries/retail-ecommerce Screen supplied sellers, suppliers, vendors, payout recipients, and relevant commerce counterparties against configured sources without disrupting routine checkout or fulfilment. Key points: - Customer and seller screening - Supplier and vendor review - High-value order checks - Refund and payout screening Detail: Built for checkout, seller, supplier, and payout workflows Retail and e-commerce teams may not always have bank-style AML obligations, but they still face sanctions, restricted-party, counterparty, supplier, payment, and reputational exposure. Checklynx helps teams screen the people and businesses around orders, sellers, suppliers, refunds, and payouts. Workflow: From commerce signal to documented decision A buyer signup, seller onboarding event, high-value order, refund, supplier review, or payout trigger becomes owned review work with match context and decision evidence attached. Related workflow: Connect e-commerce screening to API checks, batch review, and cases Retail screening is strongest when checkout-friendly API checks, seller review, supplier batch screening, case management, and audit evidence share the same decision trail. Can screen or support: - Customers: Buyer and account checks - Sellers: Merchant and marketplace review - Suppliers: Vendor and partner screening - Evidence: Cases, rationale, audit trail Capabilities: - Screen customers and high-value orders: Check buyers, account holders, payment details, high-value orders, unusual refund activity, and payment counterparties when the workflow or risk policy requires review. - Review sellers and marketplace merchants: Screen sellers, merchants, directors, UBOs, payout recipients, store names, and business identifiers before activation or payout release. - Keep supplier and vendor risk visible: Screen suppliers, vendors, fulfilment partners, distributors, and business counterparties through API, portal, batch, or monitoring workflows. Workflow moments: - Customer signup: Buyer, account holder, country, identifier, sanctions, adverse media, or watchlist context Risk can be checked without slowing ordinary low-risk checkout flows. - High-value order: Customer, shipping destination, payment detail, order value, payment reference, or counterparty Potential exposure is reviewed before fulfilment or release. - Seller onboarding: Merchant, company, director, UBO, payout recipient, store name, or business identifier Marketplace risk is checked before activation or payout. - Supplier review: Supplier, vendor, distributor, fulfilment partner, or business counterparty Restricted-party and reputational exposure stays visible. - Outcome recorded: Decision, rationale, reviewer, timestamp, attachments, and audit trail The business can explain who decided what and why. FAQs: - Do e-commerce companies need sanctions screening? Many retail and e-commerce businesses use sanctions or restricted-party screening to manage exposure around customers, sellers, suppliers, vendors, payment counterparties, destinations, refunds, and payouts. Specific legal obligations vary by jurisdiction and business model. - Should online retailers screen suppliers and high-value customers? Supplier, vendor, seller, and high-value customer screening can help teams identify sanctions, restricted-party, adverse media, counterparty, and reputational exposure before onboarding, fulfilment, refund, or payout activity continues. - How can screening work without slowing checkout? Checklynx supports API checks, batch screening, reusable decisions, and case review so teams can apply screening at the right risk points instead of manually reviewing every ordinary transaction. - Does Checklynx claim every retailer has AML obligations? No. Retail and e-commerce pages should focus on sanctions, counterparty, supplier, restricted-party, payment, and reputational-risk exposure. AML obligations depend on the products, geography, payment model, and regulated activities involved. Operational handoff: Reduce repeated screening work across commerce operations Screening should not make operations teams rebuild the same evidence packet every time a seller is paid, a supplier is reviewed, or a high-value order is checked. Checklynx keeps decisions, source context, and monitoring history connected to the profile and case. - Customer or order hit: Review sanctions, adverse media, and watchlist context with account details, identifiers, destination context, order value, and payment data. - Seller or merchant review: Screen marketplace sellers, payout recipients, directors, UBOs, and store records before activation or payout. - Supplier and vendor review: Batch screen suppliers, distributors, fulfilment partners, vendors, and business counterparties before or after onboarding. - Known false positive: Reuse prior decisions where appropriate so the same non-risk hit does not create repeated manual work. Operational handoff rows: - Potential sanctions hit: Case review with source context Analysts can decide before fulfilment, payout, or release. - Seller payout trigger: Screening and case handoff Marketplace payouts can be reviewed, held, or cleared with evidence. - Supplier refresh: Batch or monitoring run Vendor and counterparty risk stays current. - Governance request: Case evidence and immutable audit trail Operations and compliance can explain the decision record. ### Sanctions Screening Software for SaaS and Technology Platforms URL: https://checklynx.com/en/industries/saas-technology Screen supplied customers, enterprise accounts, vendors, resellers, partners, and relevant counterparties without turning signup or procurement into a manual review bottleneck. Key points: - Customer signup screening - Enterprise account review - Vendor and partner checks - API-first workflow integration Detail: Built for signup, enterprise, vendor, and partner workflows SaaS and technology companies do not all have the same AML obligations as regulated financial firms, but they still need to manage sanctions, restricted-party, customer, vendor, reseller, partner, and reputational exposure. Checklynx helps teams add screening where risk enters the platform without making every user flow manual. Workflow: From platform signal to documented decision A signup, enterprise account, vendor onboarding, reseller review, restricted-country signal, or procurement request becomes owned review work with match context and decision evidence attached. Related workflow: Connect SaaS screening to API checks, monitoring, and cases SaaS screening is strongest when signup checks, enterprise review, vendor screening, ongoing monitoring, and audit evidence share the same decision trail. Can screen or support: - Customers: Signup and account checks - Enterprise: Client and procurement review - Partners: Reseller and vendor screening - Evidence: Cases, rationale, audit trail Capabilities: - Screen customers without slowing every signup: Check users, companies, admins, enterprise accounts, restricted countries, and customer identifiers at signup, contract review, or risk-triggered events. - Review vendors, resellers, and partners: Screen vendors, integration partners, marketplace partners, resellers, agencies, affiliates, directors, and business counterparties before activation or periodic review. - Keep screening evidence ready for enterprise deals: Preserve source-backed match context, analyst rationale, notes, escalation history, decisions, and timestamps for procurement, security, legal, and compliance questions. Workflow moments: - User signup: User, admin, company, country, domain, identifier, sanctions, adverse media, or watchlist context Risk can be checked before account activation or feature access. - Enterprise onboarding: Customer company, director, UBO, buyer, subsidiary, reseller, or procurement counterparty Enterprise risk can be reviewed before contract approval. - Vendor review: Vendor, partner, reseller, marketplace app, affiliate, or business counterparty Restricted-party and reputational exposure stays visible. - Risk trigger: Restricted geography, account change, payment event, ownership change, or adverse media update Compliance or operations receives a focused review task. - Outcome recorded: Decision, rationale, reviewer, timestamp, attachments, and audit trail The business can explain who decided what and why. FAQs: - Do SaaS companies need sanctions screening? Many SaaS and technology companies use sanctions or restricted-party screening to manage exposure around customers, enterprise accounts, vendors, resellers, partners, restricted geographies, and counterparties. Specific legal obligations vary by jurisdiction and business model. - When should a SaaS company screen customers or partners? Screening can happen at signup, enterprise contract review, vendor onboarding, reseller approval, payment events, restricted-country triggers, periodic reviews, and ongoing monitoring updates. - How can screening be added to signup or enterprise onboarding? Checklynx supports API checks, batch screening, manual review, reusable decisions, and case workflows so teams can apply screening at the right risk points without making every account manual. - Does Checklynx claim every SaaS company has AML obligations? No. SaaS and technology pages should focus on sanctions, restricted-party, customer, vendor, partner, counterparty, and reputational-risk exposure. AML obligations depend on the product, geography, payment model, and regulated activities involved. Operational handoff: Reduce repeated screening work across platform operations Screening should not make teams rebuild the same evidence packet every time a customer signs up, an enterprise deal closes, or a vendor is reviewed. Checklynx keeps decisions, source context, and monitoring history connected to the profile and case. - Customer or account hit: Review sanctions, adverse media, and watchlist context with profile details, account metadata, country context, domain, and identifiers. - Enterprise review: Screen companies, buyers, subsidiaries, directors, UBOs, resellers, and procurement counterparties before contract approval. - Vendor and partner review: Batch screen vendors, marketplace partners, resellers, affiliates, integration partners, and business counterparties before or after onboarding. - Known false positive: Reuse prior decisions where appropriate so the same non-risk hit does not create repeated manual work. Operational handoff rows: - Potential sanctions hit: Case review with source context Analysts can decide before activation, access, or contract approval. - Enterprise deal review: Screening and case handoff Sales, legal, and compliance can align around one report record. - Vendor refresh: Batch or monitoring run Vendor and partner risk stays current. - Governance request: Case evidence and immutable audit trail Security, legal, and compliance can explain the decision record. ### Supplier and Restricted-Party Screening Software for Manufacturers URL: https://checklynx.com/en/industries/manufacturing-supply-chain Screen suppliers, distributors, resellers, customers, vessels, aircraft, and trade counterparties across sanctions, restricted-party, adverse media, and watchlist data. Key points: - Supplier and distributor screening - Restricted-party checks - Trade counterparty review - Batch screening for vendor files Detail: Built for supplier, distributor, customer, and shipment review Manufacturers and supply chain teams need to manage sanctions, restricted-party, export-control, supplier, customer, vessel, aircraft, and reputational exposure across global networks. Checklynx helps teams screen the counterparties and assets around supplier onboarding, distributor review, shipments, and periodic vendor refreshes. Workflow: From supply chain signal to documented decision A supplier onboarding event, distributor review, customer check, shipment trigger, vessel match, aircraft match, or vendor refresh becomes owned review work with match context and decision evidence attached. Related workflow: Connect supplier screening to batch review, monitoring, and cases Supply chain screening is strongest when supplier onboarding, vendor-file batch screening, shipment review, ongoing monitoring, and audit evidence share the same decision trail. Can screen or support: - Suppliers: Vendor and partner checks - Trade: Customer and counterparty review - Transport: Vessel and aircraft screening - Evidence: Cases, rationale, audit trail Capabilities: - Screen suppliers and distributors: Check suppliers, vendors, distributors, resellers, agents, directors, UBOs, and business counterparties during onboarding, renewal, or periodic due diligence. - Review trade customers and counterparties: Screen customers, buyers, consignees, intermediaries, freight partners, payment counterparties, and destination context before exposure grows. - Include vessels and aircraft where relevant: Use vessel and aircraft screening for trade, logistics, transport, leasing, shipping, aviation, and high-risk counterparty workflows. Workflow moments: - Supplier onboarding: Supplier, vendor, director, UBO, country, identifier, sanctions, adverse media, or watchlist context Risk is checked before supplier approval or activation. - Distributor review: Distributor, reseller, agent, intermediary, owner, or related company Channel risk can be reviewed before appointment or renewal. - Shipment trigger: Customer, consignee, vessel, aircraft, freight partner, destination, or counterparty Potential exposure is reviewed before shipment, delivery, or release. - Vendor refresh: Supplier file, distributor book, customer list, vessel list, or aircraft list Existing records can be batch rescreened or monitored over time. - Outcome recorded: Decision, rationale, reviewer, timestamp, attachments, and audit trail The business can explain who decided what and why. FAQs: - Why should manufacturers screen suppliers? Supplier screening helps manufacturers identify sanctions, restricted-party, adverse media, ownership, counterparty, and reputational exposure before onboarding, renewal, procurement, shipment, or payment activity continues. - What should supply chain teams screen? Teams can screen suppliers, vendors, distributors, resellers, agents, customers, consignees, freight partners, directors, UBOs, vessels, aircraft, destinations, and payment counterparties. - How can batch screening support supplier due diligence? Checklynx supports CSV batch screening for supplier, distributor, reseller, customer, vessel, and aircraft files, making periodic reviews and remediation exercises easier to run from one controlled workflow. - Does Checklynx replace export-control legal review? No. Checklynx supports sanctions, restricted-party, adverse media, watchlist, vessel, aircraft, monitoring, case review, and audit evidence workflows. Export-control obligations and legal decisions depend on product, destination, jurisdiction, and transaction facts. Operational handoff: Reduce repeated screening work across supplier and trade operations Supply chain screening should not make teams rebuild the same evidence packet every time a supplier renews, a distributor is reviewed, or a shipment is checked. Checklynx keeps decisions, source context, and monitoring history connected to the profile and case. - Supplier or distributor hit: Review sanctions, restricted-party, adverse media, and watchlist context with company details, identifiers, ownership context, and relationship status. - Customer or shipment review: Screen customers, consignees, freight partners, vessels, aircraft, destinations, and payment counterparties before shipment or release. - Vendor-file batch screening: Batch screen supplier, distributor, reseller, customer, vessel, and aircraft files before migration, renewal, or periodic review. - Known false positive: Reuse prior decisions where appropriate so the same non-risk hit does not create repeated manual work. Operational handoff rows: - Potential sanctions hit: Case review with source context Analysts can decide before supplier approval, shipment, or release. - Shipment trigger: Screening and case handoff Trade operations can hold, review, or clear activity with evidence. - Supplier refresh: Batch or monitoring run Vendor and counterparty risk stays current. - Governance request: Case evidence and immutable audit trail Trade, legal, and compliance can explain the decision record. ## Featured knowledge-base resources ### The Future of AML Is Agentic URL: https://checklynx.com/en/resources/knowledge-base/agentic-aml-compliance Agentic AML Compliance lets authorised AI agents call governed, tenant-scoped Checklynx screening and research tools across onboarding, payments, supplier checks, and investigations. Checklynx supplies structured screening results while customers retain responsibility for policy, review, escalation, and final decisions. Key points: - AML is moving from software that compliance teams visit to trusted compliance capabilities that authorised agents can use. - MCP supports agent-orchestrated AML workflows; the portal remains for people and the API for deterministic software events. - Current agent-accessible scope: sanctions, PEP, wanted-list and adverse-media screening; supported exact identifiers; batch screening; and retained-result retrieval within the authorised customer context. - The commercial value is reduced navigation, re-entry, retrieval, and formatting around analyst work, not headcount replacement or automated compliance judgement. ## Company ### About Checklynx URL: https://checklynx.com/en/company/about Checklynx builds practical AML screening and compliance workflows for regulated teams. Key points: - Financial crime compliance focus - Screening-first product architecture - Operational simplicity - Cost-conscious delivery ### Contact URL: https://checklynx.com/en/contact