Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
AML AI ist so eingerichtet, dass das Geldwäscherisiko für eine Branche bewertet wird. Eine Geschäftseinheit ist mit einem Ihrer Einzelhandels- oder Geschäftskunden verknüpft.
Wenn Sie einen Datensatz für die Verwendung mit einer Fachabteilung erstellen, müssen Sie mehrere Tabellen angeben. Jede Tabelle sollte einen ausreichenden Zeitraum abdecken. Auf dieser Seite finden Sie einen Überblick über die benötigten Tabellen und erfahren, wie Sie den Zeitraum für jede Tabelle festlegen.
Zu verwendende Tabellen
Das BigQuery-Dataset, das mit AML AI verwendet wird, sollte die folgenden Tabellen enthalten:
Partei: Alle für diese Geschäftseinheit relevanten Parteien
Retail LoB: Alle Privatkunden, die im angegebenen Zeitraum Konten hatten
Kommerzielle Kundensegmente: Alle Kunden des kommerziellen Bankgewerbes (Rechtssubjekte und natürliche Personen), die in dem erforderlichen Zeitraum Konten hatten
AccountPartyLink: Vollständiger Verlauf, welche Konten von welchen Parteien gehalten wurden. Dies sollte alle Konten für Produkte und Dienstleistungen abdecken, wenn eine Partei in der Tabelle „Party“ zu irgendeinem Zeitpunkt im erforderlichen Zeitraum der Hauptkontoinhaber war.
Transaktion: Alle Transaktionen für Konten in der Tabelle „AccountPartyLink“ für den angegebenen Zeitraum.
RiskCaseEvent: Alle Risikofallereignisse (siehe Ereignistypwerte) für jeden Risikofall und jede Partei in der Tabelle „Party“ mit einem AML_PROCESS_START (Beginn der Prüfung) im erforderlichen Zeitraum. Diese Tabelle kann Ereignisse enthalten, deren Ereigniszeit vor oder nach dem erforderlichen Zeitraum liegt.
PartySupplementaryData: (falls verwendet) Geben Sie für 0 bis 100 eindeutige Werte für „party_supplementary_data_id“ einen vollständigen Verlauf der Werte dieser Felder für alle Parteien in der Tabelle „Party“ für den erforderlichen Zeitraum an.
Zusätzliche Daten verwenden
Weitere Informationen finden Sie unter Ergänzende Daten, wenn Sie zusätzliche Daten zu den Parteien haben (die im Schema nicht anderweitig abgedeckt sind), die für die Identifizierung des Risikos von Geldwäsche relevant sind.
Zeitspanne des Datensatzes
Der Zeitraum, den eine Tabelle in einem Datensatz abdecken sollte, kann für jeden Vorgang so ermittelt werden: Sie benötigen folgende Informationen:
Die Endzeit. Das ist das Datum, ab dem Labels und Daten zum Generieren von Funktionen für die Optimierung verwendet werden.
Der Vorgang, den Sie ausführen: Optimieren, trainieren, vorhersagen oder Backtest.
Bei Vorhersage- oder Backtest-Vorgängen muss im API-Aufruf die Anzahl der Zeiträume angegeben werden, für die der Vorgang ausgeführt werden soll.
Bestimmen Sie zuerst die Anzahl der Zeiträume, die für den Vorgang verwendet werden. Das ist die Anzahl der aufeinanderfolgenden Monate, die mit dem letzten vollen Kalendermonat vor dem angegebenen Endzeitpunkt enden und für die die AML-KI die Modellfunktionen bewertet.
Bei Vorhersage- und Backtest-Vorgängen ist dies die Anzahl der im API-Aufruf angegebenen Prognose- oder Backtestzeiträume.
Bei anderen Vorgängen hängt dies von der Engine-Version und dem Vorgang ab.
Bei der Engine-Version v004.004 werden beispielsweise 18 Perioden für die Optimierung und 15 für das Training verwendet.
Als Nächstes sollten Sie das Lookback-Window für jede Tabelle ermitteln. Das ist die maximale Anzahl von Monaten an Daten, die aus dieser Tabelle für die AML-KI benötigt werden, um Modellmerkmale für einen bestimmten Zeitraum zu berechnen.
Bei der Engine-Version v004.004 sind das beispielsweise 13 Monate für die Tabellen „Transaction“ und „AccountPartyLink“, 12 Monate für die Tabelle „RiskCaseEvent“ und 0 Monate für die Tabellen „Party“ und „PartySupplementaryData“.
Der Datensatz muss das Rückschaufenster für alle Zeiträume abdecken, die für den ausgewählten Vorgang verwendet werden. Mit der folgenden Formel können Sie die Anzahl der vollständigen Kalendermonate mit Daten vor dem Endzeitpunkt berechnen, die Sie für einen bestimmten Vorgang benötigen:
Anzahl der Zeiträume + Lookback-Window – 1
Für die Optimierung von Engine-Versionen vom Typ v004.00X benötigen Sie beispielsweise:
18 + 13 − 1 = 30 Monate Daten aus den Tabellen „Transaction“ und „AccountPartyLink“,
18 + 12 − 1 = 29 Monate Daten aus der Tabelle „Ereignisse für Risikofälle“ sowie alle neueren Ereignisse für Risikofälle in der Tabelle,
Und 18 + 0 - 1 = 17 Monate Daten aus den Tabellen „Party“ und „PartySupplementaryData“.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-17 (UTC)."],[[["\u003cp\u003eAML AI assesses money laundering risk for a specific Line of Business (LoB), associated with either retail or commercial customers.\u003c/p\u003e\n"],["\u003cp\u003eCreating a dataset for AML AI requires including several tables: Party, AccountPartyLink, Transaction, RiskCaseEvent, and optionally PartySupplementaryData, each with defined content requirements.\u003c/p\u003e\n"],["\u003cp\u003eThe required time range for each table in the dataset is determined by the operation type (tune, train, predict, or backtest), the engine version, the end time, the number of periods, and the lookback window specific to each table.\u003c/p\u003e\n"],["\u003cp\u003eFor predict and backtest operations, the number of periods is defined in the API call, while for other operations, it is determined by the engine version.\u003c/p\u003e\n"],["\u003cp\u003eFor v004.00X Engine Versions conducting tuning, the dataset will need 30 months of data from Transaction and AccountPartyLink, 29 months from Risk Case Events and 17 from Party and PartySupplementaryData tables, at minimum.\u003c/p\u003e\n"]]],[],null,["# Understand data scope and duration\n\nAML AI is set up to assess money laundering risk for one\n[line of business](/financial-services/anti-money-laundering/docs/concepts/glossary#lob). An LoB is associated with one of your retail or\ncommercial customers.\n\nWhen creating a dataset for use with an LoB, you will need to include several\ntables. Each table should cover a sufficient time range. This page gives an\noverview of the tables you will need and shows how to determine the time range\nthat each should cover.\n\nTables to use\n-------------\n\nThe BigQuery dataset used with AML AI should contain the following tables:\n\n- **[Party](/financial-services/anti-money-laundering/docs/reference/schemas/aml-input-data-model#party)** : All parties relevant to that LoB\n - **Retail LoB**: All retail banking customers that have held accounts at any point in the required time range\n - **Commercial LoB**: All commercial banking customers (legal and natural entities) that have held accounts at any point in the required time range\n- **[AccountPartyLink](/financial-services/anti-money-laundering/docs/reference/schemas/aml-input-data-model#accountpartylink)**: Full history of which accounts were held by which parties. This should cover all accounts for products and services when any party in the Party table was the primary account holder at any point in the required time range.\n- **[Transaction](/financial-services/anti-money-laundering/docs/reference/schemas/aml-input-data-model#transaction)**: All transactions for accounts in the AccountPartyLink table for the required time range.\n- **[RiskCaseEvent](/financial-services/anti-money-laundering/docs/reference/schemas/aml-input-data-model#riskcaseevent)**: All risk case events (see event type values) for any risk case and party in the Party table with an AML_PROCESS_START (start of investigation) in the required time range. This table may include events that have an event time earlier or later than the required time range.\n- **[PartySupplementaryData](/financial-services/anti-money-laundering/docs/reference/schemas/aml-input-data-model#partysupplementarydata)**: (If used) For 0 to 100 unique party_supplementary_data_id values, include a full history of the values of these fields for all parties in the Party table for the required time range.\n\nUsing additional data\n---------------------\n\nSee [Supplementary data](/financial-services/anti-money-laundering/docs/reference/schemas/aml-input-data-model#supplementary-data-tables) if you have additional data on parties\n(not otherwise covered in the schema) that is relevant to identifying money\nlaundering risk.\n\nDataset time range\n------------------\n\nThe time range that any table in a dataset should cover can be worked out as\nfollows for any given operation. You will need to know:\n\n- The end time. This is the latest time from which labels are used and from which data is used to generate features for tuning.\n- The Engine Version (See [list of engine versions](/financial-services/anti-money-laundering/docs/private/engine-versions)) you will use.\n- The operation you will conduct: tune, train, predict or backtest.\n- For predict or backtest operations, the number of periods for which you will conduct the operation, to be specified in the API call.\n\nFirst you should work out the number of periods the operation will use. This is\nthe number of consecutive months ending in the last full calendar month prior to\nthe specified end time, for which AML AI will evaluate model features.\n\n- For predict and backtest operations, this is the number of prediction periods or backtest periods specified in the API call.\n- For other operations this depends on the Engine Version and the operation. For example, v004.004 Engine Versions use 18 periods for tuning and 15 for training.\n\nNext you should work out the lookback window for each table. This is the maximum\nnumber of months of data needed from that table for AML AI to calculate model\nfeatures for a given period.\n\n- For example, for v004.004 Engine Versions, this is 13 months for Transaction and AccountPartyLink tables, 12 months for the RiskCaseEvent table and 0 months for Party and PartySupplementaryData tables.\n\nThe dataset will need to cover the lookback window for all of the periods used\nby the chosen operation. You can calculate the number of full calendar months of\ndata prior to the end time that you will need for a given operation with the\nfollowing formula:\n\n- **number of periods + lookback window -1**\n\nFor example, for v004.00X Engine Versions conducting tuning, you require:\n\n- 18 + 13 - 1 = 30 months of data from the Transaction and AccountPartyLink tables,\n- 18 + 12 - 1 = 29 months of data from the Risk Case Events table as well as any more recent events for risk cases in the table,\n- And 18 + 0 - 1 = 17 months of data from the Party and PartySupplementaryData tables."]]
