Frequently asked questions

Active liveness requires a random action from the user, such as smiling, turning their head, or blinking. Passive liveness, on the other hand, performs micro-expression, depth, and reflection analysis on a single selfie, delivering the same decision without requiring any action from the user. The passive method increases completion rates, while the active method provides extra assurance for high-risk applications.

Photos and identity details read from the chip are digitally signed by the government, making them much harder to forge than a photo of the front of the document. When the selfie comparison is performed against this official photo, the matching score becomes far more reliable.

No. Document reading, chip verification, liveness, face matching, and compliant video calls are built into the platform. You do not need to allocate additional budget for separate licenses.

All verification runs on the institution's own infrastructure. Selfies, document images, and chip data are not sent to external cloud environments, making it easier to meet special categories of personal data obligations under KVKK.

An ultimate beneficial owner is the natural person who ultimately controls or benefits from a legal entity. In practice, a shareholding of 25% or more is typically used as a threshold, but individuals who exercise control through signature authority or management control are also evaluated, even if their shareholding percentage is lower.

KYC verifies individual customers through identity documents, biometrics, and screening. KYB, on the other hand, verifies legal entities and additionally requires resolving the ownership structure to identify the natural persons behind them. The KYB process also includes KYC checks for every natural person in the chain.

When a change is detected, the company's risk score is recalculated. If a new shareholder appears on a sanctions list or has a PEP record, an alert is generated immediately, without waiting for the next periodic review.

The chain is traced until natural persons are reached; there is no fixed limit on the number of layers. Structures that cannot be resolved or that contain loops are flagged for investigation rather than being silently bypassed.

No. The institution defines the handover conditions based on its own risk appetite. It is typically triggered by low face matching scores, document suspicion, or screening hits. Other applications are completed via the biometric flow.

In a setup where the customer can select the agent or vice versa, the call cannot provide the assurance required for remote identity verification. Random routing from a pool eliminates this possibility, and the assignment log can be presented as evidence during audits.

Screenshots and audio recordings are stored within the institution's own infrastructure, linked to the relevant customer record. They are never transferred to an external provider and remain accessible throughout the legal retention period.

Being on a sanctions list is a legal restriction, making it illegal to transact with that person. A PEP status is not a prohibition but a risk indicator. You are free to work with a politically exposed person, but it requires enhanced due diligence.

Serious allegations against a person can appear in the press long before they are reflected on official lists. Adverse media screening closes this gap and enables the early detection expected by a risk-based approach.

The match threshold can be adjusted by segment, records previously closed as false positives are remembered, and matches are presented to the compliance officer along with a pre-analysis. The goal is not to reduce the number of matches, but to highlight those that require investigation.

Global sanctions lists are retrieved daily. The entire customer database is rescreened every night, so any new match appears as an alert the very next day.

They are closely related. Adverse media screening typically runs on content compiled by a pre-packaged data source. In OSINT, the institution defines the sources itself: publications not included in pre-packaged sets, such as local press and industry newsletters, can also be monitored.

Matching is not based solely on name: it is evaluated alongside other identity data in your possession, and results are presented with a score. Furthermore, because every finding is linked to the source news article, the compliance officer can verify the decision.

The institution can block them if desired, but the default behavior is to flag the profile as high risk and generate an alert for review. The final decision depends on the scenario written by the institution.

The link pattern to follow, depth, and maximum page count are defined separately. The crawl targets only the section specified by the pattern rather than the entire site, and it is not unlimited.

Yes. You can view the status and completion time of the process, and the raw response is stored so you can audit exactly what the extraction process read.

Yes. Analysis prompt presets are structures with a name and a template, which are linked to sources, feeds, and documents. This distinction is necessary because extracting names from an official gazette decision is different from extracting them from a squad list.

No. It stores the first name, last name, corporate title, aliases, gender, date of birth, birth year, and city. The birth year is a separate field because official sources often only provide the year.

No. A record can be flagged as either, and both enter the same screening flow, but the source of the record and its associated authority remain clearly distinguishable.

Threshold-based monitoring only looks at the amount, and fraudsters easily learn these limits. In real-time and risk-based monitoring, the amount is evaluated alongside the context of the behavior: the customer's history, transaction time, sector, device, and counterparty relationships are also taken into account.

These are events that do not involve fund movements but alter the risk profile, such as logins from a new device, email changes, or updates to the ownership structure. A significant portion of account takeover cases begin with this type of event before any funds are transferred.

TruvaLI is designed to operate in environments with millions of daily transactions and returns decisions in milliseconds. Heavy reporting tasks are executed in the background to avoid keeping users waiting.

An alert is generated when an event meets the conditions of a scenario defined by the institution. The alert then becomes a structured case for investigation, showing which rule was triggered by which data within the case.

It is updated on an event basis, not periodically. When a new transaction, device change, profile update, or screening match occurs, the score is recalculated instantly.

Yes. The signals contributing to the score and their weights are recorded: the reason behind a decision can be traced directly within the case. This is crucial for documenting your risk-based approach.

Yes. Signal weights and decision thresholds are adjusted according to the institution's risk policy, and changes can be tested on historical data before going live.

Rule-based detection looks at predefined conditions and makes decisions explainable. AI-based detection can capture undefined patterns but is difficult to justify. TruvaLI combines both: patterns discovered by AI are converted into rules that undergo human approval.

Usually through signals that precede fund withdrawals: login from an unrecognized device or IP, followed immediately by an email or phone number change, and transaction attempts at unusual hours. Because TruvaLI also monitors these non-financial events, it can catch the chain before any money moves.

They are written in the same rule engine, but they can be separated into distinct rule sets and authorization groups. This allows the fraud team and the compliance team to use the same infrastructure without modifying each other's rules.

No. Scenarios are created by building logic blocks in the interface or by describing them in daily operational language. The expression editor is only there for advanced cases requiring custom calculations.

It is not limited to pre-set periods like days and months. Free-form time windows like 'the last 73 hours' or volume-based windows like 'the last 15 transactions' can be defined.

Yes. By triggering a callback to your core system from within the rule, a transaction can be suspended, additional verification can be requested, or the account can be restricted. Depending on the institution's maker/checker settings, putting the decision into production may be subject to approval.

No. A rule can be run against your historical data to preview the alert volume and false positive rate it will generate. For details, see the rule sandbox and simulation page.

Historical data can be transferred into the system during implementation, allowing meaningful testing from the beginning. The institution can choose the test period, and longer periods may be preferred when seasonal effects need to be evaluated.

The alerts the rule would have generated historically are compared with how similar cases were resolved during the same period. The result is an estimate, but it provides a more reliable basis than publishing a rule without measuring its likely impact.

Yes. Running the same rule with multiple thresholds and comparing the results is one of the main uses of simulation. This allows the threshold to be determined through measurement rather than guesswork.

Yes. Rules with consistently high false positive rates can be flagged and threshold improvement recommendations can be provided, helping the rule set remain effective over time.

The generated rule does not go straight to production. It appears on the screen with its parameters, allowing you to edit it and simulate it on historical data. Additionally, going live is subject to an approval workflow.

Compliance and risk terminology: expressions such as age limits, ID number formats, activity codes, time windows, and amount thresholds are resolved from context. The term 'minor' converts into an age condition, and 'foreign national' converts into ID number and nationality conditions.

Most scenarios do not require code. For advanced cases requiring custom calculations, there is an expression editor in the rule engine, but this is an additional capability rather than a necessity.

An alert is a technical output showing that a rule has been triggered. A case is a work record created to investigate that alert, with an assigned owner, timeline, and decision rationale. From an audit perspective, the key question is not only how many alerts were generated, but how cases were reviewed and resolved.

When an analyst (maker) closes a case or publishes a rule, the action is submitted to a predefined approval pool for review by a checker. The decision does not become effective until approval is received. Once approved, a callback can be sent to the institution's main system.

The age of each case is monitored, cases approaching their deadlines are flagged, and they can be escalated to management when required. Since the queue can be prioritized by risk score, limited investigation capacity can be focused on the highest-risk cases.

No. Alerts arising from the same reason can be closed in bulk, and a common rationale can be applied to all of them. This helps prevent repetitive situations from consuming unnecessary investigation capacity.

No. Pre-analysis is a recommendation. The compliance officer makes the decision and adds their own comments. For low-risk cases, one-click closure may be suggested, but this is still subject to the approval workflow.

Yes. The signals on which the assessment is based are clearly documented: the triggered rule, customer history, and IP and device patterns. This makes it possible to demonstrate how the decision was reached during audits.

No. The analysis runs on the institution's own infrastructure. Customer data, transaction details, and case content are never sent to external cloud environments.

They should be used as drafts. They may be too narrow or too broad, so thresholds should be adjusted according to the institution’s risk appetite and tested through simulation before being put into use.

Patterns can be identified from a single case, but when similar cases are analyzed together, common elements can be separated more reliably and the resulting rule can be more accurate.

A ready-made library covers general industry typologies. Rules generated from historical cases are based on attacks that have actually occurred within your own product and customer base. The two approaches are complementary rather than alternatives.

No. The draft is prepared for review, and the compliance officer reads, edits, and approves it. The institution remains responsible for the content and submission of the report; the system does not assume this responsibility.

No. Reports can be created by selecting fields and filters through the interface or by describing the required report in natural language, after which the system generates the query.

Yes. Reports can be scheduled to run daily, weekly, or monthly and can be delivered to relevant users in PDF or Excel format.

The institution determines which actions are subject to approval. Rule publishing and case closure are the two most commonly used steps: authorization groups and approval pools are defined according to the institution's own hierarchy.

No. Records are kept in an immutable format, and archive integrity is verified with hash values. A legally valid timestamp is added to approvals.

Down to the screen, button, and data level. A user may view a screen but not perform a specific action within it: sensitive fields can be displayed with masking.

Yes. Data sources are managed independently, and each department only sees its own source, rule set, and alerts.

Yes. The analysis layer, including case pre-analysis, open-source screening, and report generation, runs on your own servers: customer data is never sent to external services.

The platform is designed to process high volumes with limited resources: scoring across millions of records is completed in milliseconds with a modest server configuration. Exact requirements are determined together based on your transaction volume.

It is migrated into the system before going live. This ensures that your scenarios using lookback windows, such as 'the last 6 months', run with your real data from day one.

Releases are applied to your own environment during scheduled maintenance windows. Running the deployment offline does not hinder the update process.

An ISO/IEC 27001 information security management certificate and a SOC 2 Type II independent attestation report, alongside ISO 22301 (business continuity), ISO/IEC 20000-1 (IT service management), ISO 9001 (quality), ISO 37001 (anti-bribery), ISO 10002 (customer satisfaction) and ISO 45001 (occupational health and safety). Scope and validity details are shared on request.

Both. The founding team includes compliance officers who have carried personal responsibility in supervisory audits, and they usually run the product demonstrations.

Today's focus is payment systems and institutions, electronic money institutions, closed-loop wallets, loyalty systems and SPK-regulated crypto-asset service providers. Before those, the decision engine was hardened in high-volume regulated gaming infrastructure, where real-time decisions are mandatory.

Yes. Field mapping is dynamic, connecting without changing the bank's own data model. Card, loan, and branch records can also be linked to the same customer view; a portion of the types in the guide already require reading these systems together.

The guide states the opposite: obliged parties should not limit themselves to the listed types and must report any transaction that raises suspicion, even if it does not match any of them. The types are a minimum common ground, not a ceiling.

Not with an on-premise deployment. The software runs on the bank's own infrastructure, data remains in the bank's information systems, and keys and the audit trail are under the bank's control. Cloud and private cloud are also options; the decision belongs to the bank.

Yes. The rule is run on historical traffic in rule simulation to see the alert volume it will generate. You can also specify any date you want and see the result on that day's traffic.

The regulator of banking activities is BDDK. The counterparty for money laundering and terrorist financing obligations is MASAK.

Most indicators require reading customer, account, transaction, and channel data together; in banks, this data usually resides in separate systems.

The relationship network between accounts is mapped via shared IPs, devices, phone numbers, addresses, and counterparties; this reveals clusters that are not visible when looking at individual accounts.

The application sends events, and the system returns the score and decision. Non-financial events also go through the same path and are used in rules.

It depends on the license you hold: TCMB for e-money and payment services, BDDK for lending and finance, and SPK for crypto assets and capital markets brokerage. Regarding money laundering obligations, the authority is always MASAK.

By ensuring that rule changes do not require development tickets. Controls are written in your own words, drafts are tested in simulation, and deployed to production upon approval.

As the customer base grows, the number of alerts increases, and at a certain point, the team can no longer realistically investigate them. Alerts are closed, but they are closed without justification, which surfaces during audits.

Not if the level of control adapts to risk. Simplified due diligence is applied to low-risk applications, while enhanced due diligence is applied to high-risk ones, with the difference defined as a rule.

The provider and structure of the email address, whether the IP address is a proxy or VPN, and whether there are other applications connecting from the same device or address.

No. It generates a preliminary assessment during case investigation, while the final decision remains with the human and is recorded with its justification.

Having the onboarding file, transaction history, and case reside on the same record eliminates integration costs and the data collection burden during audits.

Yes. The new threshold is run against historical traffic to see how many alerts it will produce before going live.

IP data must be collected at onboarding, stored in the customer record, and compared across accounts. TruvaLI extracts the connection network between accounts via shared IP, device, phone, and email. This corresponds to type T-006-2.62 in the guide.

Yes. The rule engine supports flexible aggregation windows, meaning rules that compare against the account's historical average are set up within a single rule. The threshold is determined by the institution's own risk policy.

Merchant category data must be analyzed alongside the transaction record. Once the category data is linked, type T-006-2.27 in the guide can be turned into a rule.

Not with an on-premise deployment. The software runs on the institution's own infrastructure, data remains within the institution's information systems, and keys and the audit trail are under the institution's control.

The operational regulator is TCMB. For money laundering obligations, the authority is MASAK.

Individual top-ups and withdrawals may appear normal; the pattern emerges in the balance accumulating in the account and the relationship between top-ups and withdrawals.

The accumulation of sub-threshold amounts across the same account or related accounts is calculated via aggregation windows, and attempted transactions also remain in the records.

No. Email and IP scores serve as inputs for subsequent rules and cannot be obtained retroactively if they are not collected at onboarding.

No. Most merchant types in the guide are read from data generated after the merchant is onboarded: chargeback rates, round amount density, volume relative to sector averages, and transferring balances to third parties. KYB begins with onboarding and continues with monitoring.

Yes. When a website address is provided, the site can be scanned end-to-end, its content extracted, and adverse media and open-source records about the merchant classified by risk type. Types T-006-2.28, T-006-2.35, and T-006-2.40 in the guide require this.

Not with an on-premise deployment. The software runs on the institution's own infrastructure, data remains within the institution's information systems, and keys and the audit trail are under the institution's control.

The guide states the opposite: obliged parties should not limit themselves to the listed types and must report any transaction that raises suspicion, even if it does not match any of them. The types are a minimum common ground, not a ceiling.

The operational regulator is TCMB. For money laundering obligations, the authority is MASAK.

The institution is responsible for the merchant's activity and the legitimacy of that activity; risk is largely concentrated in what the merchant sells.

This is a well-known issue in the sector and one of the first things monitoring looks at: deviations in volume, product category, and chargeback rates change the risk classification.

Deviations in transaction volume from declarations, rising chargeback rates, changes in product categories, and changes in ownership structure.

Yes. MASAK publishes a dedicated suspicious transaction report guide for this sector and expects reports to be submitted electronically via MASAK.Online.

The guide states the opposite: obliged parties must not limit themselves to the listed types and must submit a report even if a suspicious transaction does not match any of them. The types are a minimum common ground, not a ceiling.

No. If the server where the account was opened and the IP of the first login are not recorded at that moment, they cannot be retrieved retroactively. A portion of the types in the guide rely directly on this first-contact data.

T-010-2.36 considers a customer holding a role or position that could influence the outcome of the game they play to be an indicator of suspicion. TruvaLI supports creating internal lists for these individuals and integrating them into the screening workflow.

Yes. Operators in the field of gaming and betting are obliged parties under Law No. 5549 and are subject to MASAK's sector-specific guide.

In a remotely opened player account, email, phone, and IP are often the only verifiable information available: if this data is not collected at onboarding, it cannot be generated retroactively.

The guide lists occupational declaration as an indicator: a disproportion between the declared occupation and gaming volume raises suspicion. Occupation is not a field left in the onboarding form: it is a rule input.

Clusters of accounts connecting via the same device, IP, payment instrument, and similar email addresses are uncovered through relationship networks.

Yes. The screening workflow accepts the wallet address alongside the individual's name, and the institution can create its own address lists. Type T-010-2.8 of the guide covers attempts to transfer to individuals or addresses on lists of banned or wanted persons.

A relationship network among customers must be extracted via the destination address. It cannot be detected by looking at a single account. This is Type T-010-2.27 of the guide.

The address and the counterparty platform must be classified. This data comes from the institution's own systems or integrated data sources; the rule engine combines this with time-dependent conditions.

Not in an on-premise deployment. The software runs on the institution's own infrastructure, data remains within the institution's information systems, and keys and the audit trail are under the institution's control.

In Türkiye, the operational regulator is SPK. In terms of money laundering obligations, the authority is MASAK.

No. The wallet address is accepted as an entity alongside the individual's name in the screening workflow; on-chain and off-chain data converge in the same customer view.

Direct sanctions matches, distance to a listed address, mixer exposure, cluster relationships, and the path of funds.

Yes. The direct supervision definition in Regulation (EU) 2024/1620 specifically lists crypto asset service providers.

The guide defines its scope around intermediary service providers, meaning platforms where third parties make sales. A business selling its own products on its own website is not the direct target, but most of the indicators listed have equivalents in any e-commerce structure that accepts payments.

The guide lists an unusually high number of return transactions under T-020-2.21, and the use of fake cards along with the detection of fake product purchases under T-020-2.31. Fraud control and money laundering control look at the same data.

Four types in the guide are directly related to products and prices: the sale of prohibited products, off-market pricing, frequent and sudden price changes, and sending different or fake products instead of the ordered item. A system that only looks at the payment flow will not detect any of them.

Not in an on-premise deployment. The software runs on the institution's own infrastructure, data remains within the institution's information systems, and keys and the audit trail are under the institution's control.

Yes. They are obliged parties under Law No. 5549 and are subject to MASAK's relevant sectoral guide.

Not in the transaction itself, but in the authenticity of the product, price, and parties. Payment for a product that is never actually delivered is recorded as a regular sale.

Yes. Product category, price, and cart contents are rule inputs; a price that significantly deviates from market value is an indicator.

Yes. The relationship network between the parties is mapped through shared device, IP, payment instrument, and address.

No. Credit risk asks whether the borrower will repay, while fraud risk asks whether the application is genuine. An application with a perfect credit score can be made with a stolen identity.

An identity created by combining real and fabricated information builds a credit history and pays regularly for a period. Therefore, device, network, and email signals create a layer independent of credit history.

It starts with document reading: chip reading via NFC on chipped documents, liveness testing, and face matching validate each other. Someone who copies a document cannot bypass both the chip and liveness checks.

The text of the uploaded document is read, and the amount, date, and party information within are converted into structured data, making it comparable with the declaration.

Yes. Applications coming from the same device, IP, or similar email addresses are unpacked using a relationship network: if one application is suspicious, others linked to it are also put under review.

Yes. Identity verification, identifying the ultimate beneficial owner (UBO), sanctions and PEP screening, and suspicious transaction reports are mandatory. The regulator of the institution is BDDK.

An unexpected bulk closure raises questions about the source of funds and is subject to monitoring.

Yes. How many applications a new rule will reject and how many of those are actually fraud is measured against historical application traffic before going live.

Yes. The client assigns the receivable, but the debtor is the party that pays it, so both are screened against sanctions and PEP lists and both carry a risk score. On a cheque or a bill the drawer and the endorsers are screened too.

The client is onboarded once, but its debtor portfolio changes with every assignment. A list checked at onboarding is out of date by the second transaction, so screening runs continuously and re-runs when a name enters a list later.

The text of the invoice is read and the amount, date and party information in it become structured data, which is compared with the client's declared sector and turnover and with the rest of its portfolio. The same amount circulating between related companies is what a circular invoicing rule looks for.

Yes. Identity verification, identifying the real beneficiary, sanctions and PEP screening, continuous monitoring and suspicious transaction reports are obligations, and each has to be evidenced with a record of when it was done and by whom.

A debt settled long before its due date, or settled by someone who is not the debtor, raises a question about where the money came from. Both cases are written as rules, so they are raised as alerts rather than noticed by hand.

Yes. Screening, KYB, monitoring and case management share one rule engine and one audit trail, so a decision about a client and a decision about its debtor are not taken in two systems that cannot see each other.

The guideline defines its own scope as insurance and reinsurance brokers. Most of the indicators it lists stem from the nature of the brokerage relationship and apply across the entire insurance chain, but the guideline specifically addresses brokers.

A change in beneficiary, representative, or payment source triggers a new screening and a new risk assessment. The decision made on day one does not remain static.

Yes. All four, including the representative, are recorded as separate parties and screened against sanctions, PEP, and internal lists. For corporate parties, the ownership structure is resolved to identify the ultimate beneficial owner (UBO).

The payment source is recorded and compared alongside the party structure. Types T-012-2.15 and T-012-2.16 of the guideline cover the purpose of concealing the source of funds and payments through entities in countries known as tax havens.

Not with an on-premise deployment. The software runs on the institution's own infrastructure, data remains within the institution's information systems, and keys and the audit trail are under the institution's control.

The relevant MASAK guideline specifically addresses insurance and reinsurance brokers in terms of its scope.

Not in the payment of the premium, but in whose name, with whose funds, and for what reason the policy is established. Early cancellation and transfer are also indicators.

The policyholder, the insured, and the beneficiary are recorded as separate parties, and each is screened against sanctions, PEP, and internal lists.

No. Beneficiary changes, early cancellations, additional premiums, and transfers occur later and are subject to monitoring.

The majority of the guide's sector-specific types focus on the merchant. Volume spikes, incomplete or incorrect registration details, manipulated reviews, failure to act on complaints, and sudden activity after prolonged inactivity are listed individually.

Under T-020-2.26, the guide considers the detection of unrealistic positive reviews or manipulated feedback about a merchant to be an indicator of suspicion. This means that the platform's own reputation system is also a data source that must be monitored.

Yes. Concealing the ultimate beneficial owner (UBO), the third party directing the transaction not being a party to documents, and complex multi-jurisdictional structures are separate types in the guide. They cannot be addressed without resolving the ownership structure of the company behind the store.

Not with an on-premise deployment. The software runs on the platform's own infrastructure, data remains within the platform's information systems, and keys and the audit trail are controlled by the platform.

Because it facilitates transactions for goods it does not sell itself, it is responsible for verifying the authenticity of both the merchant and the buyer; it is an obliged party under Law No. 5549.

Identity and ownership structure, activity category, consistency between declared information and public footprint, and links to previously closed merchant accounts.

Yes. A network of relationships established through shared devices, IPs, payment methods, and addresses reveals these connections.

Yes. Platform-specific fields such as product category, price, shipping, and return behavior are used as rule inputs.

Not by its amount, but by the relationship between the parties. The sender, receiver, frequency, country, transaction history, and time window are analyzed together.

Organizations providing money transfer services generally operate under a payment institution license and are subject to MASAK's guideline for payment and electronic money institutions.

Yes. The guideline also covers attempts in structuring; rejected and incomplete transfers remain in the records. Since events are ingested using upsert logic, updates do not generate new records but re-evaluate the existing record.

Yes. Both are recorded as separate parties and screened against sanctions, PEP, and internal lists.

Yes, but not by looking at a single sender account. The relationship network around the target must be extracted using shared IPs, devices, phone numbers, emails, and counterparties.

Transferring funds deposited from ATMs in different provinces into a single account, and withdrawing loads made to an inactive account from ATMs at the maximum amount, are distinct types in the guideline; they cannot be analyzed without channel information.

Email and IP scores. The guideline considers loading funds into accounts belonging to different unrelated individuals from the same IPs as an indicator, and this data cannot be generated later.

From the same case data. The decision is linked to the case with its justification and evidence, and the signature remains with the institution.

In the KYB flow, the structure is unraveled to identify the ultimate beneficial owner (UBO), and each layer is recorded individually. Types T-011-2.11 and T-011-2.13 of the guide require this.

No, they are not generated by an automated rule. The customer representative's observation is added to the case as a note, stored alongside the evidence, and included in the justification of the report.

No, it covers investment trusts. However, the weight of the indicators it lists points to a common challenge for capital market institutions: identifying the actual person behind the transaction.

Not in an on-premise deployment. The software runs on the institution's own infrastructure, data remains within the institution's information systems, and keys and the audit trail are under the institution's control.

The operational regulator is SPK. In terms of anti-money laundering obligations, the authority is MASAK.

Not in the profit of the transaction, but in whose name the account is opened and the economic logic of the transaction. Transactions performed at a loss or without economic justification are indicators.

It is unraveled layer by layer down to the ultimate beneficial owner (UBO); each natural person in the chain undergoes sanctions and PEP screening.

Yes. A bulletin, decision text, or PDF list is uploaded; the text is read, and the individuals and entities within it are converted into structured records.

The Council of Europe's MONEYVAL committee evaluation on anti-money laundering and combating the financing of terrorism.

No. Each country is defined as a separate data source: the same deployment hosts different rule sets, and one country's threshold does not affect another.

The risk-based approach, customer identification, ultimate beneficial owner (UBO) identification, and suspicious transaction reports share a common framework. Reporting thresholds, reporting formats, retention periods, and authority expectations vary.

Yes. Since both are in the process of aligning with the EU acquis, the framework established by (EU) 2024/1620, (EU) 2024/1624, and (EU) 2024/1640 sets their compliance target.

From 1 July 2025. It directly supervises selected obliged parties in the financial sector, including crypto-asset service providers.

It is written into the rule engine: nested logic, named aggregation definitions, and callbacks from rules are supported. The rule can be described in your own language and tested on historical traffic before going live.

Bitrelic has a team in Podgorica: we track regulatory changes and authority expectations by having a physical presence in the region.

In an on-premise deployment, within the institution's own information systems: keys and the audit trail are under the institution's control. Since data residency rules vary from country to country, this is a decisive factor in regional deployments.

No. Each country is defined as a separate data source; the same deployment carries different rule sets, and one country's threshold does not affect another.

It is diversity, not complying with a single regulation. Reporting thresholds, identity verification requirements, retention periods, and authority expectations vary from country to country.

No. The ratio of foreign national customers, the weight of worker remittances, and cash habits vary even within the region; a volume that is normal in one country can be an indicator of suspicion in another.

Transfers to or from high-risk countries that reach significant amounts within a certain time frame without a reasonable explanation are a common indicator; the sender and receiver context, time window, and repetition are analyzed together.

Yes. When remittance and transfer flows cross multiple jurisdictions, the transaction may need to be evaluated against two different regimes simultaneously.

It is written into the rule engine: nested logic, named aggregation definitions, and callbacks from rules are supported. The rule is tested on historical traffic before going live.

Customer records, screening infrastructure, case management, audit trail, and report drafting remain in a single place; a separate system is not deployed for each country.

In an on-premise deployment, within the institution's own information systems; keys and the audit trail are under the institution's control.

Law No. 6698 regulates the protection of personal data used in analysis. The classification of biometric data as special category and the restriction of international transfers to an adequacy decision are two decisive points.

Yes. The second paragraph of Article 12 of the Law provides for joint liability in taking measures if data is processed by another party on behalf of the data controller.

Yes. Article 6 of the Law classifies biometric data as special category and, as a rule, prohibits its processing: processing is only possible under one of the specified conditions.

Pursuant to Article 9, data can be transferred if one of the conditions in Articles 5 and 6 is met and an adequacy decision exists regarding the country, sector, or international organization to which the transfer will be made.

It is issued by the Board, published in the Official Gazette, and re-evaluated at least once every four years.

The fifth paragraph of Article 12 of the Law requires that if data is obtained through unlawful means, the situation must be reported to the data subject and the Board as soon as possible.

Yes. Access is recorded in the audit trail: role and authorization definitions, approval policies, and delegation of authority are logged separately, and the log can be exported to a separate destination.

The document image, data read from the chip, selfie, liveness video, and call recording are recorded separately: the collection time, the check in which it is used, and the retention period of each can be managed individually.

Article 25, which regulates data protection by design; Article 32, which lists security of processing; and Article 9, which classifies biometric data as a special category.

The use of aliases and encryption; the ability to ensure the confidentiality, integrity, availability, and resilience of systems and services; the ability to restore access in a timely manner in the event of an event; and a process for regularly testing, assessing, and evaluating the effectiveness of the measures.

It is not sufficient. Article 32(d) requires regular testing, assessing, and evaluating the effectiveness of the measures.

Yes. Article 9 prohibits, as a rule, the processing of biometric data for the purpose of uniquely identifying a natural person, and only permits it under specific conditions.

Article 25 requires measures to be taken at the time of determining the means of processing; the choice of deployment model falls under this scope. In an on-premise deployment, data remains within the organization's information systems and keys are under the organization's control.

Through access, decision, and approval logs. Since the audit log can be exported to a separate destination, it can also be evaluated within the organization's own logging infrastructure.

The document image, data read from the chip, selfie, liveness video, and call recording are recorded separately; the collection time, the check it is used in, and the retention period of each are managed individually.

The rule engine shows which field is used in which rule; when it is traceable which decision a field enters, it can be seen whether an unnecessary field is being processed.

Liability is personal as much as it is corporate. When auditors ask questions, they address that individual, and if the answer is not in the records, there is no defense.

Why a rule was written with that specific threshold, why a case was closed, why a report was not filed, who approved the decision, which rule set was running in the past, and who accessed the data.

No. Controls can be written in your own words, and the corresponding draft rule is generated automatically. The draft does not go live without approval and is first tested in simulation.

When the team is overwhelmed, alerts are not actually reviewed, yet the records show an investigation was conducted. This is the hardest scenario to defend during an audit.

No. It generates a preliminary assessment from the case data, but the decision remains with the human and is logged with its justification.

No. Approval policies, multi-signature decisions, and delegation of authority can be defined, and the delegation itself is recorded alongside its documentation.

Directly from the case itself. The date range, total amount, channel breakdown, and suspicion category already reside within the case. The signature and filing decision rest with the compliance officer.

Our team of compliance and fraud practitioners have done this work inside banks for over fifteen years. You can reach someone who has answered that exact question from their own desk.

It is not identifying the threat, but translating that insight into the system. When the rule writer and the risk expert are different people, every change enters a request queue.

No. You write the control in your own words to generate a draft rule, which never goes live without approval.

No. Contributing to a score, adding an alert reason, or simply flagging the transaction are also valid outcomes. This allows you to monitor aggressive rules before deploying them to production.

Yes. Events without monetary values, such as logins, device changes, document uploads, and setting modifications, are also used in rules.

The rule is run against historical transaction traffic, showing how many transactions it would block, how many alerts it would generate, and how many of those actually turn out to be fraud, all before going live.

Yes. The rule can be replayed against that day's traffic to see exactly what the outcome would have been.

Yes. The signal pattern within the case can be extracted and converted into a rule, keeping institutional knowledge within the organization rather than with individuals.

Yes. The sequence in which rules are evaluated can be defined, and the rule's owner and sharing permissions are also recorded.

Your application sends an event, and the system returns the score, triggered rules, and the decision. The decision is returned fast enough to be used inline within the flow.

No. Logins, device changes, document uploads, setting changes, and account openings are also events, and they are used in rules in the exact same way.

No. Data sources are kept separate, and rules can be scoped by source.

A customer's transaction count, sum, and average within a period are pre-defined and referenced by name in rules.

No. Rules exist as data, not code; compliance and fraud teams can modify rules without entering the engineering queue.

The specific rule set and version executed are stored alongside the result of each event, making it possible to trace which rule caused the change.

It can be hosted on the organization's own infrastructure. Data never leaves the organization, logs remain on your own systems, and the audit trail can be sent to a separate destination.

With a single flow that causes the most losses or generates the most alerts. Events for that flow are sent, rules are run in simulation, and the results are compared with your existing system.

Control systems are living systems; rules and thresholds change. Explaining a decision from six months ago using today's rule set yields incorrect results.

If the specific rule and the version that triggered it are not stored alongside the event, the justification for a past decision cannot be reconstructed.

A subset is selected from the cases of a specific period using filters. Report definitions are created without code, results are saved, and the same definition can be run again in the subsequent period.

No. In an on-premise deployment, all logs remain within the institution's own infrastructure, so the audit itself does not create a data risk.

Decisions prepared and approved by the same person can be queried. Approval policies, multi-signature decisions, and delegation of authority remain in the logs.

How many times it was triggered, how many cases it turned into, how many went to reporting, and how many were closed without justification are measured. A rule that never triggers and a rule that triggers everything are both audit findings.

Yes. The rule is run on historical traffic, and the before and after of the change can be compared.

It cannot be altered. Logs can also be sent to a separate destination, so a change within the platform does not affect the audit trail.

The guides state the opposite: obliged parties must not limit themselves to the listed types, and must file a report even if a suspicious transaction does not match any of them. The types represent a minimum common ground, not a ceiling.

Yes. Matters such as suspicious account openings and closures, safe deposit box visits, or power of attorney and guarantee transactions are written in the description section of the form. The case must be capable of carrying these types of events.

When filing a report, the suspicion is mapped to one of the 38 categories in MASAK's reference table, and each category is matched with a legal regulation. Case management must operate with this taxonomy rather than arbitrary custom tags.

The guides set a clear threshold: there must be documents or serious indications supporting the suspicion, going beyond mere suspicion, and the report must be submitted with its justifications. This requires evidence to be attached to the case and the identity of the decision-maker to be recorded.

Law No. 5549 designates a wide range of institutions as obliged parties: banks, payment and electronic money institutions, capital markets institutions, insurance companies, crypto asset service providers, and operators in the field of games of chance are among them.

The guides list sector-specific indicators and establish a floor. If a pattern not listed in the guide raises suspicion, the obligation to report still applies.

Application procedures and all submissions for suspicious transaction reports are carried out electronically through the MASAK.Online system.

Yes, you can. A rule can be described in your own words to generate a draft, tested on historical traffic before going live, and put into effect upon approval.

It is the European Union's authority for anti-money laundering and countering the financing of terrorism, established by Regulation (EU) 2024/1620.

The Regulation was adopted on 31 May 2024 and has been applicable since 1 July 2025. Certain articles have been in force since 26 June 2024, and one article will apply from 31 December 2025.

Selected obliged parties in the financial sector, including crypto-asset service providers. It also coordinates and oversees financial and non-financial sector supervisory authorities.

Regulation (EU) 2024/1620, Regulation (EU) 2024/1624, Directive (EU) 2024/1640, and Regulation (EU) 2023/1113, which regulates information accompanying transfers of funds and certain crypto-assets.

Supervision is no longer a relationship maintained solely with national authorities; selected obliged parties are directly supervised by AMLA.

Yes. Countries and business units are defined as separate data sources; rule and data isolation is managed through this separation, allowing a single deployment to support the rule sets of different jurisdictions.

No. In the screening workflow, a wallet address is treated as an entity alongside the individual's name; on-chain and off-chain data merge into a single customer view.

The reasoning behind every decision must be auditable. Details on who made the decision, under what authority, using which data, and when, are written to an immutable audit trail; which rule was triggered by which event is also recorded.

OCR and MRZ reading from document images, chip reading via NFC for chipped documents, liveness testing, face matching, and video calls where required by regulations. The layers verify one another; a single check is never the sole basis for onboarding.

Data read from the chip comes directly from the document itself. While checks based on image processing can be fooled by a high-quality copy, chip reading cannot be spoofed.

The ownership structure is resolved layer by layer down to the natural person. Every natural person identified in the chain also undergoes sanctions and PEP screening, with every step of the path recorded.

The provider is matched against lists of trusted, disposable, and privacy-focused providers. The address is checked to see if it contains the person's first name, last name, date of birth, or initials, and a fuzzy search is run against similar or sequentially numbered addresses in the system.

By analyzing geolocation, ownership information, and rDNS records, the system determines whether the address is a proxy, VPN, or residential service provider. Finding other accounts using the same IP is a separate risk signal.

Yes. Where risk is low and regulations permit, fewer documents are requested; high risk triggers enhanced due diligence. Which threshold leads to which outcome is defined by the institution's own rules.

Applications that exceed the score threshold are routed to human review. Decisions are recorded with their justification, subject to segregation of duties, and written to the audit trail.

On the institution's own infrastructure in an on-premise deployment. Document images, call recordings, and screening results remain linked to the decision and can be presented as evidence later.

During customer onboarding, at the moment of transaction, across the entire existing customer base when lists change, and during periodic reviews based on risk classification.

Aliases and transliterations, date of birth, ID and passport numbers, nationality, and city information are evaluated together. The photo is retrieved from the source and displayed with a confidence score, and the validity date of the record is also checked.

No. The validity dates of the record are read, and a lifted decision does not generate an alert.

Yes. Every record is stored with the issuing authority and its country, and the source link is also preserved.

Yes. Through official source definitions, feed polling, or document uploads, the institution's own lists enter the same screening workflow.

Since verification signals are stored in the record, name similarity alone does not generate alerts. Where the threshold is set is written as a rule, and how many alerts a new threshold will generate on historical traffic is previewed via simulation.

A match opens a case. The review, decision, and approval chain is logged with its justification and written to an immutable audit trail. If a notification is required, the case is converted into a report.

Not in an on-premise deployment. Lists, screening, and decisions all remain entirely within the institution's own infrastructure.

Senders, beneficiaries, the beneficiary's bank, and any intermediary institutions. Name and address information in free-text fields is also covered, as a sanctioned party often appears in the description line.

Screening is embedded directly into the transaction pipeline and operates within a latency budget. The result must return fast enough to be part of the decision; otherwise, screening is effectively disabled.

It is not rejected; it is suspended. The suspended transaction is linked to a case, and a human makes the decision.

Confirmation signals such as aliases, date of birth, ID and passport numbers, nationality, and city are stored in the record, so a common name alone does not stop a payment. The effective date of the record is also checked.

Yes. Sanctions regimes target countries and sectors as much as individuals; the route of the transfer may require verification even if all parties are clear.

Yes. How many transactions the new threshold would stop in historical payment traffic is measured via simulation before the rule goes live.

Yes. Both releasing and stopping are decisions; both are written to the immutable audit trail with their justification and are subject to segregation of duties.

Yes. The institution's own lists enter the same screening flow via official source definition, feed, or document upload.

It evaluates transactions against the customer's own history, declared activity, peer groups, below-threshold structuring patterns, and network relationships established through shared devices, IPs, or accounts.

Yes. A new sanctions record, adverse media finding, a series of transactions inconsistent with declarations, or a change in ownership structure elevates the risk class: monitoring frequency and the review schedule change accordingly.

Yes. As lists change, the existing customer base is re-screened, because a record that is clean today might match later.

Before a rule goes live, it is run against historical traffic to measure how many alerts it will generate. A threshold that drowns the team is just as problematic as one that misses risks.

No. The required control can be written in plain language, and its equivalent is generated as a draft rule: the draft does not go live without approval.

Yes. Which version of which rule triggered the alert is recorded with the event, allowing a past decision to be explained using the rule set active on that day.

An alert becomes a case. Following the investigation, the case is closed, snoozed, or escalated to a report: the justification and decision are written to the audit trail.

No. The declaration and profile collected at onboarding serve as the baseline for monitoring: without a declaration, deviations cannot be measured.

Because the login is successful. The password is correct, and in most cases, multi-factor authentication has also been bypassed; the takeover becomes visible in post-login behavior.

New device ID, the proxy or VPN status of the IP, impossible travel between two sessions, shared devices, funds leaving the account following a settings change, and unusual transaction speed.

No. What makes a takeover visible is the combination of signals; a new device, a VPN, and funds leaving after an IBAN change together form a single strong pattern.

Yes. Account clusters connected via the same device, IP, or email pattern are revealed through link analysis; a suspicious account opens up others sharing the same device for investigation.

Whether the provider is reputable, disposable, or privacy-focused generates a risk score. The similarity of the address to other addresses in the system via fuzzy matching, and clusters of addresses with sequential endings, serve as additional indicators.

The evaluation runs inline within the transaction flow and is fast enough to make a decision. A slow check provides the correct answer only after the money has left, which has no practical value.

The new threshold is run against historical session and transaction traffic, showing how many legitimate users would be blocked before the rule goes live.

Yes. The signal pattern within the case can be extracted and converted into a rule, ensuring the same path cannot be exploited twice.

Because a single account behaves in compliance with the rules: the user registers, claims the bonus, and meets the requirements. The violation lies in the relationship between the accounts.

Device ID, IP and network, payment method, email patterns, identity detail combinations, and behavioral synchronicity.

Addresses are scanned against each other using fuzzy matching; this reveals highly similar or sequentially numbered email clusters. The use of disposable email providers serves as an additional signal.

No, it is not. The characteristics of the IP address are just one of many signals; the final decision depends on the combination of signals and the rules defined by the institution.

This risk is real, which is why the number of accounts a new threshold would catch in historical traffic is measured before the rule goes live.

No, it is not. You can describe what the check should be in your own words, and the corresponding draft rule is generated; the draft does not go live without approval.

The cluster triggers a case where the accounts, the links between them, the triggered rule, and the investigator's justification are kept together. Revoking the bonus or clearing the cluster is recorded as a decision.

Yes. Which rule and version was triggered, and who made the decision with what justification, is recorded in an immutable audit trail.

A dispute fee is added to the refunded amount for each transaction, and the payment processor imposes sanctions if the chargeback rate exceeds a certain threshold. The third is the most expensive because it impacts the merchant's license to operate.

Device ID, proxy or VPN status of the IP, match between billing/shipping addresses and IP location, card velocity, email attributes, and cart behavior.

No. The decision depends on the aggregation of signals and the threshold set by the institution.

Yes. Clusters of accounts and transactions linked by the same card, device, or email pattern are uncovered using link analysis.

No. Raising the threshold reduces chargebacks but also lowers legitimate sales. The optimal threshold is found by balancing these two costs.

Yes. The rule is run against historical transaction traffic, allowing you to see how many transactions it would reject and how many of those would actually turn into disputes before going live.

Device and IP information at the moment of transaction, address matching, session history, and delivery records. Having this data stored alongside the transaction determines your leverage during the dispute process.

Yes. The pattern of the case can be extracted and converted into a rule, ensuring the same path cannot be exploited again.

No. Source of funds asks about the origin of the money in a specific transaction, while source of wealth asks where a person's total assets come from. A customer may be able to explain their wealth but fail to explain the funds in a single transaction.

An amount disproportionate to the declared profile, a sudden change in behavior, a high-risk counterparty or country, a PEP relationship, and adverse media findings.

Evidence supporting the declaration: such as a sales contract, payslip, inheritance certificate, dividend resolution, or loan agreement. The text of the document is read, converting the parties, amounts, and dates within it into structured data.

No. The declaration, document, and transaction behavior are evaluated together; the document supports the declaration, while the transaction behavior tests it.

Yes. Sending parties, intermediary accounts, and associated individuals are examined; connections established through a shared device, IP, or address can reveal structures that are invisible when viewed individually.

The inquiry shifts to the wallet: the history of the address where the funds originate, its contact with mixing services, and its proximity to sanctioned addresses are analyzed.

The explanation is deemed sufficient and the case is closed, additional documentation is requested and the case is deferred, or the explanation remains insufficient and proceeds to a report.

The declaration, documents, screening results, transaction history, and the investigator's justification all reside within the same case. The question asked during an audit is usually why it was closed, and the answer is right inside the case.

It is not filled out from scratch on a separate reporting screen: it is generated directly from the case itself. The date range, total amount, channel and type distinction, party information, and suspicion category already reside in the case.

No. The guideline does not require writing all financial transactions of the customer with the obliged party that are not deemed suspicious into the form: the report carries a selection, not a full dump, and the justification for that selection resides within the case.

Yes. Suspicious account openings and closures, safe deposit box visits, and guarantee or power of attorney transactions are written in the description section of the form, leaving the suspicious transaction section blank.

Yes. If the suspicion is based on multiple transactions within a certain date range, the total amount and the date range are reported together as a multiple transaction.

It is placed into one of the 38 categories in the MASAK reference table, and each category maps to the relevant legal regulation: for example, usury and POS usury are linked to Article 241 of Law No. 5237.

Under the regulation based on Article 19/A of Law No. 5549, there must be documents or serious indications supporting the suspicion, rather than mere suspicion, that the asset is related to the crime of money laundering or financing of terrorism.

Application procedures and all submissions regarding suspicious transaction reports are carried out electronically through the MASAK.Online system.

Yes. Report definitions are made without code, and the results are saved and repeatable: where each figure originated from in terms of cases and events remains traceable.

Yes. Which version of which rule triggered the event is recorded alongside the event.

Not a person, but a blockchain address. The address's direct match with sanctions records, its distance to a listed address, mixer exposure, cluster relationship, and the path of the funds are evaluated.

It is how many steps away the address is from a listed address. Funds coming directly and funds coming through three intermediaries are not the same, but the latter is not considered clean either.

The institution. Risk appetite is written as a rule, and what the threshold will generate is measured against historical transfer traffic before going live.

It does not. The address evaluation enters the customer risk score; the customer's own profile also affects the threshold with which the address is evaluated.

Address history is part of the answer, not the whole. Declarations and supporting documentation are still required; all three are evaluated together.

It is not a ground for a decision on its own, but having passed through a service designed to obscure the origin of funds is a strong signal and can suspend the transaction depending on the institution's threshold.

A match opens a case; the address, matching record, distance, fund path, and the reviewer's justification reside together, and the decision is written to an immutable audit trail.

It does not in an on-premise deployment; evaluations and records remain within the institution's own infrastructure.

The risk is concentrated not in the business itself, but in the activities it performs and the real person behind it. The ownership structure is mapped, and the line of business is evaluated separately.

The ownership structure is mapped layer by layer down to the natural person. Every natural person in the chain undergoes sanctions and PEP screening.

Changes can invalidate the onboarding decision. This is why the structure is not mapped just once, but is continuously monitored.

The declared line of business and the products actually sold can diverge. Registering under an approved category and selling in another is a well-known industry challenge.

When the time between collection and delivery is long, if the business goes bankrupt, the chargebacks for undelivered orders fall on the payment institution.

Yes. Applications connecting with the same device, IP, email pattern, or identity credentials become visible through relationship networks.

Deviations in transaction volume from what was declared, rising chargeback rates, and changes in product categories. These deviations alter the risk classification.

Obtained documents, the mapped ownership chain, performed screenings, the resulting score, and the approver are recorded. Due to segregation of duties, the reviewer and the approver may not be the same person.

No. It is the application of the same customer screening infrastructure to a different subject. Sanctions records, internal lists, and adverse media entities reside in the same place.

Sanctions lists, PEP and associate records, adverse media, and the organization's own watchlists. Organizations can add their own lists via official source definitions, feed streams, or document uploads.

Name similarity alone is not a sufficient basis for a decision. Aliases and transliterations, date of birth, ID and passport numbers, nationality and city details, and photo confirmation are evaluated together; the record's effective date is also checked.

The screening is the same, but the legal basis and retention periods differ. Candidate data is processed for the duration of the recruitment process, while employee data is processed for the duration of the employment relationship and as prescribed by legislation.

Yes. Re-screening is performed as lists change, and any new match generates a new alert. A person who clears screening today might match a decision published later.

Three methods work in tandem: official source pages are read at defined intervals, adverse media feeds are regularly polled, and regulatory bulletins are uploaded and converted into structured records. Every record is stored with its source link.

Yes. Access is restricted by authorization, and who accessed employee data and when is written to the immutable audit trail.

Not with an on-premise deployment. All screening and records remain entirely within the organization's own infrastructure.