DE69832068T2

DE69832068T2 - Verfahren und apparat zum generieren von kenngrössen

Info

Publication number: DE69832068T2
Application number: DE69832068T
Authority: DE
Inventors: P. Kevin SIEGEL; L. Patrick FAITH; P. Theodore WASHBURNE
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 1997-05-27
Filing date: 1998-05-26
Publication date: 2006-07-13
Anticipated expiration: 2018-05-27
Also published as: AU7596098A; CA2291090A1; US6598030B1; EP0986797B1; US6018723A; DE69832068D1; CA2291090C; AU755760B2; WO1998054677A1; EP0986797A1

Description

ALLGEMEINER STAND DER TECHNIK
1. GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft allgemein Verfahren und Apparate zur Verwendung in der Finanzdatenanalyse. Insbesondere betrifft die vorliegende Erfindung Verfahren und Apparate, um effizient Kenngrößen-Variablen aus Finanztransaktionen abzuleiten, indem Vorrangverhältnisse genutzt werden, so dass die Kenngrößen-Variablen von Risikoprognose-Modellen verwendet werden können.
2. STAND DER TECHNIK
Da die Verwendung von Bankkarten immer weiter verbreitet ist, erkennen die Herausgeber von Bankkarten, dass Kredit- und Betrugsausbuchungen, einschließlich Konkursverluste, steigen. Wenn ein Bankkarten-Kontoinhaber oder -inhaberin gezwungen ist, für Zahlungen für Transaktionen, z. B. Finanztransaktionen, normalerweise seine oder ihre Bankkarte zu verwenden, sind es die Bankkartenherausgeber, die meistens gezwungen sind, die damit verbundenen Verluste aufzufangen. Um sich finanziell abzusichern, entwickeln Bankkartenherausgeber insofern so genannte „Risikoprognose"-Modelle, die sie zum Abschätzen von Risiken, wie z. B. Konkursrisiken, Betrugsrisiken und Nicht-Konkurs-Risiken verwenden, die mit einem Bankkarten-Kontoinhaber zusammenhängen. Risikoprognose-Modelle für die Betrugsaufdeckung basieren typischerweise auf der Analyse von Kenndaten, die sich in einer Reihe von Transaktionen zeigen, die von einem Bankkarteninhaber für ein einzelnes Konto ausgeführt werden.
Modelle zum Auswerten von Konkurs- und Kreditrisiken basieren typischerweise auf historischen Zahlungs- und Kontonutzungsdaten. Genauer gesagt, verwenden Risikoprognose-Modelle zur Auswertung von Konkurs- und Kreditrisiken typischerweise historische Kontonutzungsdaten, die mit einem Bankkartenkonto, oder allgemeiner, mit dem Inhaber eines Bankkartenkontos verbunden sind, um Zahlungs-Kenndaten zu identifizieren und um die Zahlungs-Kenndaten mit bekannten Zahlungs-Kenndaten in Beziehung zu bringen. Mit anderen Worten, die Zahlungs-Kenndaten des Kontoinhabers werden mit Zahlungs-Kenndaten verglichen, die auf ein vergleichsweise hohes Risiko zukünftiger finanzieller Probleme schließen lassen, wie beispielsweise Konkurs oder Kreditausfall.
Hinsichtlich Betrugserkennungs-Systemen werden beispielsweise Transaktionsdaten, z. B. Daten im Format einer Daten-Zeichenkette, die eine Reihe verschiedener Datenfelder enthält, typischerweise nicht unmittelbar vom Betrugserkennungs-Modell verwendet. Allgemein müssen die Transaktionsdaten, die solche Daten wie eine Kontonummer, einen Transaktionsbetrag, eine Transaktionszeit und einen Händler-Zip-Code sowie verschiedene weitere Daten umfassen, in Kenngrößen-Variablen umgewandelt werden, die dann als unmittelbarer Input für die Risikoprognose-Modelle genutzt werden können. Diese Kenngrößen-Variablen umfassen zum Beispiel eine Variable, die das mit einer Transaktion verbundene Risiko enthält, die in einem bestimmten geografischen Gebiet eintritt, eine zeitgewichtete Summe der Gesamtzahl abgeschlossener Finanzerwerbe, und eine laufende Summe der Gesamtzahl abgeschlossener Erwerbe.
Es sollte zur Kenntnis genommen werden, dass die Zahl der Kenngrößen-Variablen, die von Betrugsrisiko-Erkennungsmodellen verwendet werden können, zahlreich ist sowie auch dynamisch, insofern sich gewünschte Kenngrößen-Variablen ändern können. Bei herkömmlichen Betrugsrisiko-Erkennungsmodellen werden Kenngrößen-Variablen von Transaktionsdaten abgeleitet, indem fest programmierte Computerprogramme verwendet werden, die in einer geeigneten Sprache geschrieben sind, wie zum Beispiel Computerprogramme, die in der Computersprache C geschrieben sind. Fest programmierte Computerprogramme werden verwendet wegen ihrer Fähigkeit, hochvolumige Datenströme zu verarbeiten. Die Transaktionsdaten liefern den Input für die fest progammierten Computerprogramme, die dann Kenngrößen-Variablen generieren. Aufgrund des Volumens der Kenngrößen-Variablen, die potentiell genutzt werden können, sowie der Größenbeschränkungen, die mit den meisten Computerprogrammen verbunden sind, wäre es unpraktisch, wenn nicht geradezu unmöglich, ein Computerprogramm zu erstellen, das in der Lage ist, grundsätzlich beliebige mögliche Kenngrößen-Variablen zu erzeugen.
Das Anfordern von Kenngrößen-Variablen, die nicht bereits in fest programmierten Computerprogrammen berücksichtigt sind, ist deshalb nicht leicht zu erreichen. Infolgedessen erweist sich die Verwendung von fest programmierten Computerprogrammen zum Erzeugen von Kenngrößen-Variablen als nicht zufrieden stellend, da angeforderte Kenngrößen-Variablen häufig wechseln, beispielsweise, weil Betrugserkennungs-Modelle sich weiter entwickeln.
Theoretisch müssen, obwohl im Wesentlichen jede Kenngrößen-Variable durch fest programmierte Computerprogramme erzeugt werden kann, wenn eine neue, vorher nicht verfügbare Kenngrößen-Variable gewünscht wird, die fest programmierten Computerprogramme gewöhnlich neu geschrieben und kompiliert werden. Deshalb ist eine solche Vorgehensweise zum Erzeugen von Kenngrößen-Variablen häufig kompliziert, und infolgedessen ineffizient, weil das Neu-Schreiben und Neu-Kompilieren von Programmiersprachencode keine alltägliche Aufgabe ist. Weiterhin wäre es geradezu unmöglich, vorherzusagen, welche Kenngrößen-Variablen eventuell benötigt werden. Ein fest programmiertes Computerprogramm zu schreiben, das vorgesehen ist, allein solche Kenngrößen-Werte zu erzeugen, deren Verwendung vorhergesehen ist, wäre insofern eine höchst schwierige Aufgabe.
Um das Flexibilitätsproblem anzugehen, können nicht fest programmierte Computerprogramme oder Analysesysteme zum Erzeugen von Kenngrößen-Variablen verwendet werden. Sind die Kenngrößen-Variablen einmal gefunden, werden unter Anwendung des nicht fest programmierten Ansatzes die mathematischen Beschreibungen dieser Kenngrößen-Variablen typischerweise an die Wirkbetriebssystem-Programmierer ausgegeben, die dann die mathematische Beschreibung in ein Transaktions-Verarbeitungssystem codieren, indem sie z. B. C, C++, COBOL oder jede andere geeignete Programmiersprache verwenden, die die erforderlichen Transaktionsverarbeitungs-Raten erreichen kann. Solche nicht fest programmierten Computerprogramme oder Analysesysteme haben jedoch auch Nachteile, z. B. haben sie typischerweise nicht die Fähigkeit, hochvolumige Datenströme zu bewältigen.
Obwohl die vorstehende Diskussion hauptsächlich in Bezug auf Betrugserkennungssysteme vorgenommen wurde, gibt es ähnliche Probleme hinsichtlich der Ausgestaltung und der Implementierung von Konkursprognosesystemen. Wie erwähnt, unterscheiden sich Transaktionsdaten für Konkursprognosesysteme des Stands der Technik von Betrugserkennungssystemen des Stands der Technik darin, dass sie typischerweise historische Zahlungsdaten und Kontobewegungsdaten abbilden. Dennoch bedingen die Aufgabe, Kenngrößen-Variablen für Konkursprognosesystemen des Stands der Technik, die fest programmierte Computerprogramme verwenden, zu erzeugen, und der nicht fest programmierte Ansatz auch die zuvor erwähnten Nachteile für die Flexibilität und/oder Datenhandhabung.
Ein effizientes Verfahren und ein effizienter Apparat zum Umwandeln unbearbeiteter Transaktionsdaten in Kenngrößen-Variablen, ohne zu erfordern, bedeutende Anteile fest programmierter Computerprogramme umarbeiten zu müssen, während das Bewältigen hochvolumiger Datenströme ermöglicht wird, ist deshalb erwünscht. Mit anderen Worten werden ein Verfahren und ein Apparat benötigt, die es ermöglichen, im Wesentlichen jede Kenngrößen-Variable aus unbearbeiteten Transaktionsdaten leicht zu erzeugen. Es wäre ebenfalls wünschenswert, wenn ein solches Verfahren und ein solcher Apparat imstande wären, hochvolumige Datenströme in Echtzeit zu verarbeiten.
Die Internationale Patent-Veröffentlichung Nr. WO 94/20912 offenbart ein objektorientiertes System zum Erstellen, Gliedern, Bearbeiten und Auswerten eines Finanzinstruments. Ein Finanz-Rahmenwerk umfasst eine Funktions- und Datentypenbibliothek, die Finanz-Anwendungen unterstützt, indem sie einem Benutzer ermöglicht, Finanzinstrumente zu bestimmen, zu bepreisen und neu zu bewerten.
KURZDARSTELLUNG DER ERFINDUNG
Die vorliegende Erfindung betrifft Verfahren und Apparate zum Umformen skalierbarer Transaktionsdaten in Finanzdatencharakteristiken. Bezüglich eines Gesichtspunkts wandelt ein computerimplementiertes Verfahren skalierbare Transaktionsdaten in eine Finanzdatencharakteristik zur Verwendung in der Kreditrisiko-Bewertung. Die Finanzdatencharakteristik wird aus den Transaktionsdaten gewonnen. Das Verfahren umfasst, die Transaktionsdaten von einer Datenquelle zu beziehen, und einen Satz von Operationen auf die Transaktionsdaten anzuwenden, um die Transaktionsdaten in die Finanzdatencharakteristik umzuwandeln. Der Satz von Operationen wird nur aus einem vorbestimmten Satz von Operationsklassen ausgewählt, die durch eine vordefinierte Rangfolge zusammenhängen. Jede Operation im Satz von Operationen wird in einer Reihenfolge durchgeführt, die auf der vordefinierten Rangfolge einer Klasse basiert, die mit jedem Operator verknüpft ist.
In einer Ausführungsform umfasst der Satz der vorbestimmten Operationsklassen höchstens fünf Operationsklassen, die eine Datenstrukturklasse, eine atomare Umformungsklasse, eine Entity-Umformungsoperation-Klasse, eine Zeit-Umformungsoperation-Klasse und eine Zusammenführungs-Operator-Klasse sind. In einer anderen Ausführungsform ist die Finanzdatencharakteristik ausgestaltet, in einem Risikoprognose-Modell verwendet zu werden, und das Verfahren umfasst auch, die Finanzdatencharakteristik dem Risikoprognose-Modell bereit zu stellen.
KUZRBESCHREIBUNG DER ZEICHNUNGEN
Die Erfindung kann am besten mit Bezug auf die folgende Beschreibung, zusammen mit den begleitenden Zeichnungen verstanden werden, in denen:
1 eine grafische Darstellung des Datenflusses durch einen Mustererzeugungsapparat gemäß einer Ausführungsform der vorliegenden Erfindung ist.
2 eine grafische Darstellung einer Liste von Operatoren ist, die von einem Mustererzeugungsapparat gemäß einer Ausführungsform der vorliegenden Erfindung verwendet wird.
3 eine grafische Darstellung der Klassen ist, die von einem Mustererzeugungsapparat gemäß einer Ausführungsform der vorliegenden Erfindung erkannt werden.
4 eine grafische Darstellung der Vorrangverhältnisse zwischen Klassen gemäß einer Ausführungsform der vorliegenden Erfindung ist.
AUSFÜHRLICHE BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
Die vorliegende Erfindung wird nun ausführlich in Bezug auf einige ihrer bevorzugten Ausführungsformen beschrieben, wie in den begleitenden Zeichnungen veranschaulicht. In der folgenden Beschreibung werden zahlreiche spezifische Einzelheiten dargelegt, um ein vollständiges Verständnis der vorliegenden Erfindung zu bieten. Für den Fachmann ist es jedoch offensichtlich, dass die vorliegende Erfindung ohne einige oder alle dieser spezifischen Einzelheiten ausgeführt werden kann. In anderen Fällen sind wohlbekannte Strukturen und Prozessschritte nicht ausführlich beschrieben worden, um die vorliegende Erfindung nicht unnötigerweise unverständlich zu machen.
1 ist eine grafische Darstellung des bewertbaren Datenflusses durch einen Mustererzeugungsapparat gemäß einer Ausführungsform der vorliegenden Erfindung. Im Allgemeinen ist ein Mustererzeugungsapparat eine Software-Maschine, die verwendet werden kann, um bewertbare Transaktionsdaten in „Muster"-Daten oder den Output einer Reihe von Kenngrößen-Variablen für den Gebrauch in einem Risikoprognose-Modell umzuformen. Gemäß eines besonders vorteilhaften Gesichtspunkts der vorliegenden Erfindung, können bewertbare Transaktionen jeden möglichen Fall umfassen, der sich auf das Kreditrisikoniveau eines Kreditnehmers auswirken kann. Das heißt, die bewertbaren Transaktionen der vorliegenden Erfindung umfassen nicht nur Finanztransaktionsdaten (z. B. Ermächtigungen und Abrechnungen für Erwerbe von Waren oder Dienstleistungen auf Kredit oder Barentnahme auf Kredit), sondern auch allgemein zugängliche Daten, Kundenzahlungsdaten, Scheckabrechnungsverkehr und dergleichen. In der beschriebenen Ausführungsform wird ein Mustererzeugungsapparat verwendet, um bewertbare Transaktionsdaten in Kenngrößen-Variablen oder in Daten-Charakteristiken umzuwandeln, die entweder im Modellentwicklungsprozess oder einem verknüpften Transaktions-Bewertungsprozess oder in beiden verwendet werden, was nachfolgend beschrieben wird. Solch ein Mustererzeugungsapparat wird weiterhin angeordnet, um hochvolumige Datenströme in Echtzeit zu analysieren.
Gemäß einem Gesichtspunkt der vorliegenden Erfindung sind die Operatoren effizient organisiert, mit der speziellen Absicht des Bereitstellens flexibler Variablen-Charakterisierung und für Hochgeschwindigkeitsausführung. Die Operatoren, die nicht direkt zum Zweck der Erzeugung von Kenngrößen-Variablen beitragen, werden zweckmäßigerweise beseitigt, wodurch man Hochgeschwindigkeitsverarbeitung ermöglicht. Die Operatoren werden auch organisiert, um es zu ermöglichen, dass große Kombinationen von Kenngrößen-Variablen einfach durch Reorganisation der Operatoren abgeleitet werden.
Eine Input-Transaktion 104, die im Allgemeinen eine bewertbare Transaktion ist, die unter Verwendung einer Bankkarte, z. B. Kreditkarte, durchgeführt wird, wird als Input für einen Mustererzeugungsapparat 106 bereitgestellt. Der Kunde, der im Besitz der Scheckkarte ist, d.h. der Kontoinhaber, erzeugt die Input-Transaktion 104, wenn er oder sie eine Transaktion unter Verwendung der Bankkarte ausführt. Typische Transaktionen umfassen den Einkauf mit der Bankkarte und das Beschaffen von Bargeld-Vorauszahlungen mit der Bankkarte. Es sollte zur Kenntnis genommen werden, dass Transaktionen stark unterschiedlich sein können, und es dürfen durchaus nicht nur Transaktionen in Betracht gezogen werden, die mit einer Bankkarte durchgeführt werden. Beispielsweise können Transaktionen auch die Verarbeitung von Kundenkontoinformationen umfassen, um zu bestimmen, ob ein Kunde für einen Privatkredit qualifiziert ist sowie die Verarbeitung von Kundenkontoinformationen, um zu bestimmen, ob ein Scheck, der vom Kunden ausgestellt wird, voraussichtlich zurückgewiesen werden wird.
Die Input-Transaktion 104 kann durch einen Hochgeschwindigkeitsdatenstrom gekennzeichnet sein, der Datenfelder, die Informationen bezüglich einer Transaktionsart, Datenfelder, die Informationen bezüglich der in die Transaktion einbezogenen Beteiligten, und Datenfelder, die viele weitere Informationen enthalten, die auf die Transaktion bezogen sind, z. B. die Kosten einer Transaktion, umfasst, aber nicht auf sie beschränkt ist. Im Allgemeinen wird die Input-Transaktion 104 in einer Datenquelle (nicht gezeigt) gespeichert, die typischerweise entweder eine Datei oder eine Datenbank sein kann, wie zum Beispiel eine Kontodatenbank oder eine Kundendatenbank. Solch eine Datenquelle kann vom Geldinstitut gepflegt werden, das die Bankkarte herausgab, die verwendet wurde, um die Input-Transaktion 104 durchzuführen.
Sobald die Input-Transaktion 104 bezogen ist, wird die Input-Transaktion 104 als Input für einen Mustererzeugungsapparat 106 zur Verfügung gestellt. Der Mustererzeugungsapparat 106 ist hauptsächlich ein Software-Analysator, der verwendet werden kann, um im Wesentlichen jedes wünschenswerte Muster zu erzeugen, z. B. eine Finanzcharakteristik. In der beschriebenen Ausführungsform werden die wünschenswerten Muster mit einem festgelegten Satz von Operatoren erzeugt, die in einem interpretativen Programmiersprachencode verfasst werden.
Der Betrieb des Mustererzeugungsapparats 106 bezieht den interpretativen Programmiersprachencode 108, eine relationale Datenbank 110 und mehrdimensionale Tabellen 112 ein, die alle im Wesentlichen ein Teil des Mustererzeugungsapparats 106 sind. Der interpretative Programmiersprachencode 108 umfasst den zuvor erwähnten festen Satz von Operatoren, der auf die Input-Transaktion 104 angewendet wird, um die gewünschten Charakteristiken zu erzeugen. Solche gewünschten Charakteristiken können umfassen, sind aber nicht begrenzt auf, z. B. die Anzahl der Ausführungen einer bestimmten Art von Transaktion über einen festen Zeitabschnitt und die mit der Verarbeitung von Transaktionen über einen bestimmten Zeitabschnitt angefallenen Kosten. Es sollte zur Kenntnis genommen werden dass, wie in Bezug auf Tabelle 2 unten beschrieben wird, im Wesentlichen jede Charakteristik, das für ein Geldinstitut von Interesse sein kann, abgeleitet werden kann mit dem Satz von Operatoren, die mit dem interpretativen Programmiersprachencode 108 und folglich dem Mustererzeugungsmechanismus 106 verknüpft sind.
Da im Wesentlichen jede relevante Charakteristik mit dem Satz von Operatoren abgeleitet werden kann, die mit dem interpretativen Programmiersprachencode 108 verknüpft sind, sollte zur Kenntnis genommen werden, dass der Gebrauch von interpretativem Programmiersprachencode 108 ermöglicht, neue Charakteristiken zu erzeugen, indem er einfach die Operatoren kombiniert und die Werte der Operanden ändert, auf die die Operatoren wirken. Im Gegensatz zu der ineffizienten, herkömmlichen Notwendigkeit, ein fest programmiertes übergeordnetes Computerprogramm neu zu schreiben, um neue Charakteristiken zu erzeugen, verlangt die Fähigkeit, Operatoren auf einer dazwischenliegenden Programmierebene neu zu kombinieren, z. B. mit einer Pseudo-Sprache, die interpretiert werden kann, zum Erzeugen neuer Charakteristiken keine Änderungen an einem fest programmierten, übergeordneten Computerprogramm. Weiter ermöglicht der Gebrauch einer dazwischen liegenden Programmierebene auch den mit den Operatoren verknüpften Parametern, leicht verändert zu werden, tatsächlich „on the fly" oder in Echtzeit. Dadurch kann jede gewünschte Kenngrößen-Variable gewonnen werden, ohne dass Änderungen an einem übergeordneten Computerprogramm vorgenommen werden müssen.
In der beschriebenen Ausführungsform wird der interpretative Programmiersprachencode 108 durch eine höhere Programmiersprache erzeugt. Das heißt, die Operatoren, die mit dem interpretativen Programmiersprachencode 108 verknüpft sind, können in jeder geeigneten Programmiersprache kodiert werden. Beispielsweise können die Operatoren in der Programmiersprache C kodiert werden.
Die Relationale Datenbank 110 ist so angeordnet, dass sie bewertbare Transaktionsinformationen speichert. Beispielsweise können Verzögerungen oder Zeitserien von Transaktionsdaten in der relationalen Datenbank 110 gespeichert werden. In einer Ausführungsform kann die relationale Datenbank 110 entweder eine Kontodatenbank oder eine Kundendatenbank sein. Wenn die Erzeugung einer gewünschten Charakteristik den Gebrauch einer Reihe von Werten erfordert, die mit den vorhergehenden Transaktionen verknüpft sind, die auf einem bestimmten Konto vorgenommen werden, können die vorhergehenden Werte aus der relationalen Datenbank 110 im Allgemeinen beschafft werden.
Mehrdimensionale Tabellen 112 sind im Allgemeinen n-dimensionale Matrizen, die Parameter umfassen, die mehrfache „Schlüssel" haben, welche einen Händler-Bezeichner, ein Ortskennzeichen und eine Postleitzahl umfassen, aber nicht darauf beschränkt sind. Mehrdimensionale Tabellen 112 können Parameter, wie zum Beispiel Risiko-Werte, enthalten, die nicht in einer Datenbank gespeichert werden, so dass die Parameter für den Mustererzeugungsapparat 106 leicht zugänglich sind.
Ist die Transaktion 104, die wie vorher erwähnt, eine bewertbare Transaktion ist, durch den Mustererzeugungsapparat 106 verarbeitet worden, wird der „Output" 114, d.h. die Kenngrößen-Variable, entweder zu einem Modellentwicklungsprozess 116 oder zu einem Wirkbetriebs-Bewertungsprozess 118 weitergeleitet, der mit dem Modellentwicklungsprozess 116 verknüpft ist. Obgleich der Modellentwicklungsprozess 116 verwendet werden kann, um jedes geeignete Modell zu entwickeln, das die Kenngrößen-Variablen bezüglich Finanztransaktionen, z. B. Finanzdatencharakteristiken, verwendet, wird der Modellentwicklungsprozess 116 im Allgemeinen verwendet, um ein Risikoprognose-Modell zu entwickeln. Ein Risikoprognose-Modell kann verwendet werden, um mögliche Risiken zu ermitteln, die mit einem Konto oder einem Kontoinhaber verbunden sind. Beispielsweise kann ein Risikoprognose-Modell verwendet werden, um die Wahrscheinlichkeit abzuschätzen, dass ein Kontoinhaber gezwungen ist, Konkurs anzumelden, die auf den Informationen basiert, die in einer Kenngrößen-Variable bereitgestellt werden. Alternativ kann ein Risikoprognose-Modell auch verwendet werden, um die Wahrscheinlichkeit abzuschätzen, ob eine bestimmte bewertbare Transaktion betrügerisch ist. Ein Risikoprognose-Modell kann weiterhin verwendet werden, die Performance eines Portfolios zu evaluieren, um Grenzen zu setzen und das Risiko zu reduzieren, was von Fachleuten geschätzt werden wird.
Der bewertende Prozess im Wirkbetrieb 118 wird im Allgemeinen als Input für die Auswertelogik eines Modells, z. B. eines Risikoprognose-Modells, verwendet und unter Verwendung des Modellentwicklungsprozesses 116 entwickelt. Mit anderen Worten, der bewertende Wirkbetriebs-Prozess 118 kann verwendet werden, um eine Bewertung mit einem bestimmten Kennwert zu verknüpfen, so dass ein Risiko bewertet werden kann.
Mit Bezug auf 2, werden die Operatoren, die vom Mustererzeugungsapparat verwendet werden, wie bezüglich 1 zuvor erklärt, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung beschrieben. Eine Tabelle 202 verzeichnet einen Satz von Operatoren 206, die, wenn Sie in den verschiedenen Kombinationen verwendet werden, dazu dienen, Input-Daten in im Wesentlichen jeden möglichen gewünschten Output umzuwandeln. In der beschriebenen Ausführungsform ist sechzehn die Mindestzahl von Operatoren 206, die notwendig ist, um Eingangsdaten in im Wesentlichen jede gewünschte Charakteristik effizient umzuwandeln, z. B. in eine Kenngrößen-Variable, einen Indikator, ein Feature oder einen Output. Es sollte jedoch zur Kenntnis genommen werden, dass, obgleich die Mindestzahl von Operatoren 206 sechzehn in dieser Ausführungsform ist, ein optionaler siebzehnter Operator häufig in Verbindung mit den sechzehn „obligatorischen" Operatoren verwendet wird, wie nachfolgend beschrieben wird.
Die Operatoren 206 umfassen auch einen „Datenbankoperator" 210. Der Datenbankoperator 210 wird im Allgemeinen verwendet, um eine bestimmte Position innerhalb einer spezifischen Datenbank zu identifizieren, die verwendet wird oder verwendet werden wird, um eine gegebene Variable zu speichern. Zum Beispiel kann sich der Datenbankoperator 210 auf eine Speicherposition innerhalb der relationalen Datenbank 110 beziehen. Obwohl der Datenbankoperator 210 in einer Ausführungsform mit allen geeigneten Argumenten aufgerufen werden kann, umfassen Argumente oder Operanden, die dem Datenbankoperator 210 übergeben werden, typischerweise den Namen einer Datenbank, den Namen der Variablen, die in die Datenbank gespeichert werden soll, die Position in der Datenbank, wohin die Variable gespeichert werden soll, und den Variablentyp.
Die Operatoren 206 umfassen auch einen „DataBaseLag"-Operator 214. Der allgemeine Zweck des DataBaseLag-Operators 214 ist, eine Datenbank sowie Positionen innerhalb der Datenbank zu spezifizieren, in der Verzögerungen, z. B. Zeitreihen, von Variablen gespeichert werden können. In einer Ausführungsform umfassen die Argumente, die vom DataBaseLag-Operator 214 verwendet werden, den Namen einer Datenbank, den Namen einer in die Datenbank zu speichernden Variablen und die Positionen innerhalb der Datenbank, in denen die Verzögerungen der Variablen gespeichert werden sollen. Argumente, die an den DataBaseLag-Operator 214 übergeben werden, können auch die Zahl der zu speichernden Verzögerungen, den Zeitabschnitt, auf dem die Variable verzögert werden soll, und die Art der Variablen umfassen, sind aber nicht darauf begrenzt.
Ein „IndexRead"-Operator 218 ist angeordnet, um Elemente aus einer Tabelle, wie zum Beispiel einer Indextabelle, zu lesen, die in jeder geeigneten mehrdimensionalen Datenquelle, d.h. einer Sparse-Matrix, enthalten sein kann. Es sollte zur Kenntnis genommen werden, dass der IndexRead-Operator 218 im Allgemeinen nicht angeordnet ist, um mit relationalen Datenbanken verwendet zu werden. Der IndexRead-Operator 218 kann dazu verwendet werden, eine ASCII-Zeichen-Datei, die gewünschte Informationen enthält, z. B. den Mittelwert und die Standardabweichung einer bestimmten Risikocharakteristik, in eine Indextabelle einzulesen und die Informationen in eine Tabelle im Random Access Memory (RAM) zu schreiben. Das Speichern von Daten in einer RAM-Tabelle ermöglicht im Allgemeinen, schnell auf die Daten zugreifen zu können. Dem IndexRead-Operator 218 können Argumente übergeben werden, wie der Name der Datei, welche die Indextabelle enthält, der Name der Output-Datentabelle im RAM und die Anzahl der Argumente oder Parameter, die von der Indextabelle gelesen werden können.
Ein „atomarer" Operator 222 kann verwendet werden, um ein Feld von einer Input-Datenquelle einzulesen. Obgleich die Input-Datenquelle in der beschriebenen Ausführungsform entweder eine Datenbank oder eine Datei sein kann, ist die Input-Datenquelle im Allgemeinen eine Datei, wie zum Beispiel eine ASCII-Datei, oder eine Zeile, die aus einer Datenbank gelesen wird. Argumente, die verwendet werden, um den atomaren Operator 222 aufzurufen, umfassen in der beschrieben Ausführungsform einen Bezeichner, der mit einer Input-Datenquelle verknüpft ist, einen Namen für das Datenelement, das gelesen werden soll, und die Byteposition für die Anfangsposition und die Endposition des Feldes für das Datenelement, das von der Input-Datenquelle gelesen werden soll. Es sollte zur Kenntnis genommen werden, dass viele Argumente zusätzlich zu den oder an Stelle der oben erwähnten Argumenten verwendet werden können. Beispielsweise kann ein Datentyp, z. B. ein Zeichen, eine Ganzzahl oder eine Gleitkommazahl, der mit dem Datenelement verknüpft ist, ebenfalls als Argument einbezogen werden.
Der Satz von Operatoren 206 umfasst auch einen „Constant"-Operator 226, der verwendet wird, um den Wert der Konstanten anzugeben, die von anderen Operatoren 206 verwendet werden können. Der Constant-Operator 226 kann als Argument einen Namen für die Konstante, die deklariert wird, einen Typ für die Konstante und einen Wert für die Konstante nehmen. Im Allgemeinen sind die deklarierten Konstanten entweder Ganzzahlen, Zeichenketten oder Gleitkommazahlen.
Ein „Continuous"-Operator 230 ist angeordnet, um Daten einer Unterdomäne einer gegebenen Funktion anzupassen. Mit anderen Worten, der Continuous-Operator 230 wird verwendet, um Daten mit jeder geeigneten Funktion, wie zum Beispiel einer logarithmischen Funktion oder Exponentialfunktion, auf einen neuen Bereich abzubilden. In einigen Ausführungsformen ist es wünschenswert, Daten so abzubilden, dass die tatsächliche Verteilung von Daten leichter gedeutet werden kann, d.h. ein Muster in den Daten einfacher zu identifizieren sein kann. Operanden, die in einem Aufruf des Continuous-Operators 230 verwendet werden, umfassen im Allgemeinen den Namen eines Wertes oder eines Satzes von Werten, auf die gewirkt werden soll, eine Darstellung der Funktion, die zu verwenden ist, Werte abzubilden, und jede der Konstanten, die mit der Funktion verknüpft sind. Es sollte zur Kenntnis genommen werden, dass die Funktion durch einen Namen gekennzeichnet werden kann. Alternativ kann die Funktion ausdrücklich als ein Argument im Continuous-Operator 230 enthalten sein. Argumente in einem Aufruf des Continuous-Operators 230 umfassen gewöhnlich den Namen einer Variable oder von Variablen, welche die abgebildeten Resultate des Aufrufs des Continuous-Operators 230 enthalten.
Ein „Fuzz"-Operator 234 ist im Wesentlichen ein Fuzzy-Logik-Operator, der von der Fuzzy-Set-Theorie abgeleitet ist, und er dient dazu, Daten durch den Gebrauch einer Mitgliedschaftsfunktion, die Fachleuten der Informatik wohlbekannt ist, aus einer Input-Domäne auf einen Mitgliedschaftswert abzubilden. Im Allgemeinen werden Mitgliedschaftsfunktionen verwendet, um Daten zwischen unterschiedlichen Klassen in Beziehung zu setzen. Beispielsweise können die Daten, die zu einer Transaktion gehören, die an einem bestimmten Tag durchgeführt wird, ein „Mitglied" der Klasse von Daten sein, die zu den Transaktionen gehören, die während einer Woche durchgeführt wurden, die den bestimmten Tag einschließt. Einen Mitgliedschaftswert zu lokalisieren, der mit einer Input-Variablen verknüpft ist, ermöglicht diesem Wert, mit unterschiedlichen Mitgliedschaftsklassen verknüpft zu sein.
Obgleich Argumente zum Fuzz-Operator 234 in der beschriebenen Ausführungsform weit variiert werden können, können Argumente zum Fuzz-Operator 234 eine Input-Variable, den Namen einer geeigneten Mitgliedschaftsfunktion, jeden Parameter, den die Mitgliedschaftsfunktion erfordert, und den Namen der Output-Variablen umfassen, die den Mitgliedschaftswert enthält. Beispiele der Mitgliedschaftsfunktionen umfassen Gaußsche-Kurven-Mitgliedschaftsfunktionen, trapezoide Mitgliedschaftsfunktionen und generalisierte Glockenkurven-Mitgliedschaftsfunktionen, sind aber nicht darauf begrenzt.
Ein „ArraySparse"-Operator 242 ist angeordnet, um dünnbesiedelte oder verhältnismäßig leere Arrays nach bestimmten Feldern zu durchsuchen. Dünnbesiedelte Arrays können Arrays von Feldcodes umfassen, die unter Verwendung von IndexRead-Operatoren 218 abgeleitet wurden, sind aber nicht auf diese begrenzt. Der ArraySparse-Operator 242 kann als Argumente z. B. eine Risko-Indexvariable, eine Input-Indexvariable oder einen Namen einer Output-Variablen entgegennehmen. Eine Risiko-Indexvariable wird verwendet, um ein Array zu identifizieren, das Indexvariablen und Risikowerte enthält, oder Werte, die das Risiko bezeichnen, das mit einer gegebenen Variablen verknüpft ist. Eine Input-Indexvariable ist typischerweise ein Wert, der verwendet wird, um das gewünschte Feld im Array zu lokalisieren, das durch die Risiko-Indexvariable bestimmt ist. Ein Name einer Output-Variablen spezifiziert die Risikowerte, die mit erfolgreich in Übereinstimmung gebrachten Input-Indexvariablen verknüpft sind.
Die Operatoren 206 umfassen auch einen „GeneralOperator"-Operator 246, der angeordnet ist, um arithmetische Operationen und Vergleichs-Operationen durchzuführen. Es sollte zur Kenntnis genommen werden, dass arithmetische Operationen weit variiert werden können. Jedoch umfassen arithmetische Operationen in der beschriebenen Ausführungsform solche „einfachen" arithmetischen Operationen wie Addition, Subtraktion, Multiplikation, Division und Exponentiation, sind aber nicht darauf begrenzt. Ähnlich können Vergleichsoperationen auch weit variiert werden.
Vergleichsoperationen, die zwischen zwei oder mehr Einheiten ausgeführt werden, können solche Vergleichsoperatoren wie „ist gleich"-Operatoren, "ist nicht gleich"-Operatoren, „größer als"-Operatoren und „kleiner als"-Operatoren einbeziehen, wie von Fachleuten geschätzt wird. Solche Vergleichsoperatoren können auch „und"-, „oder"- und „nicht"-Operatoren umfassen, wenn Vergleiche zwischen logischen Argumenten ausgeführt werden.
In der beschriebenen Ausführungsform umfassen Argumente zum GeneralOperator-Operator 246 Variablen, auf die Arithmetik- oder Vergleichsoperationen angewandt werden sollen, eine spezifizierte Arithmetik- oder Vergleichsoperation und eine Variable, die angeordnet ist, um das Resultat der Arithmetik- oder Vergleichsoperation zu enthalten. In Ausführungsformen, in denen der GeneralOperator 246 verwendet wird, um eine laufende Summe zu errechnen, kann die Variable, die das Resultat der arithmetischen Operation enthält, dieselbe wie eine der Input-Variablen sein.
Ein "AlphaSmoothing"-Operator 250 wird verwendet, um eine gewichtete Summe, z. B. eine Zeit-gewichtete Summe für einen Satz Daten, oder genauer Transaktionsdaten, zu berechnen. In einer Ausführungsform ist die gewichtete Summe eine exponentiell geglättete Summe. Argumente zum AlphaSmoothing-Operator 250 umfassen den Namen der Variablen, die den exponentiell geglätteten Wert enthält, den Namen der „rohen" Variablen, die geglättet werden soll, und Konstanten, wie zum Beispiel einen Dämpfungsfaktor, der mit der exponentiell geglätteten Summe verknüpft ist, sind aber nicht darauf begrenzt. Es sollte zur Kenntnis genommen werden, dass die zu glättende Variable und die Variable, die den exponentiell geglätteten Wert enthält, dieselbe Variable sein können.
Ein „AlphaBetaSmoothing"-Operator 254 wird verwendet, um einen gewichteten Durchschnitt zu berechnen, wie zum Beispiel einen Zeit-gewichteten Durchschnitt. Insofern nimmt der AlphaBetaSmoothing-Operator 254 im Allgemeinen die gleichen Argumente wie der AlphaSmoothing-Operator 250 entgegen, nämlich den Namen der Variablen, die den geglätteten Wert enthält, den Namen der Variablen, die geglättet werden soll, und Konstanten. Der AlphaBetaSmoothing Operator 254 unterscheidet sich vom AlphaSmoothing-Operator 250 dadurch, dass der AlphaBetaSmoothing-Operator 254 typischerweise eine Superposition von Exponentialfunktionen einbezieht, während der AlphaSmoothing-Operator 250 gewöhnlich durch eine einzelne Exponentialfunktion gekennzeichnet ist. Weiter berechnet der AlphaBetaSmoothing-Operator 254 gewichtete Durchschnitte, während der AlphaSmoothing-Operator 250 gewichtete Summen berechnet.
Ein „Prognose"-Operator 258 wird verwendet, um eine Zeitreihe auf Input-Daten anzupassen und vorauszuberechnen. Beispielsweise kann ein Prognose-Operator 258 verwendet werden, um Vorgänge für einen gegenwärtigen oder zukünftigen Monat auf der Grundlage von Vorgängen vorhergehender Monate vorauszusagen. Argumente, die im Allgemeinen vom Prognose-Operator 258 verwendet werden, umfassen die in der Prognose-Modellierung zu verwendenden Variablen, z. B. Variablen, die sich auf Vorgänge in vorhergehenden Monaten beziehen. Andere Argumente können Variablen umfassen, die das prognostizierte oder vorhergesagte Ergebnis enthalten, sowie Variablen, die Vertrauensgrenzen zum prognostizierten Ergebnis enthalten, wie zum Beispiel obere und untere Vertrauensgrenzen.
Ein „Histogramm"-Operator 262 wird verwendet, um Statistiken zu erzeugen, die auf Input-Daten basieren, die in der beschriebenen Ausführungsform eine Reihe von Transaktionen darstellen. In einer Ausführungsform wird der Histogramm-Operator 262 verwendet, um einen Satz von Werten zu analysieren, um den Wert oder die Werte zu identifizieren, die am häufigsten für eine gegebene, mit einem Konto verknüpfte Variable auftreten. Typische Argumente, die dem Histogramm-Operator 262 übergeben werden, umfassen normalerweise eine Input-Variable, die zum Histogramm verarbeitet werden soll, die Zahl der Verzögerungen der Input-Variablen, die bei der Erzeugung eines Histogramms genutzt werden sollen, die in der Berechnung des Histogramms zu verwendende Zeitbeschränkung und eine Output-Variable, die angeordnet ist, um die Ergebnisse des Histogramms zu enthalten. Es sollte zur Kenntnis genommen werden, dass, wenn mehr als ein Output-Wert gewünscht wird, z. B. die zwei am allgemeinsten auftretenden Werte gewünscht werden, die Zahl der Output-Variablen dementsprechend erhöht werden kann.
Der „Lags"-Operator 266 ist angeordnet, um eine Reihe von Werten zusammenzufassen. Mit anderen Worten kann der Lags-Operator 266 verwendet werden, um eine spezifizierte Anzahl von verzögerten Werten für eine Variable zusammenzufassen. Die Zusammenstellung eines Falls hat gewöhnlich zur Folge, einen Wert zu erhalten, der eine bestimmte Variable charakterisiert. Solche charakteristischen Werte umfassen den Maximalwert einer Variablen, den Mindestwert einer Variablen, den Mittelwert einer Variablen und die Standardabweichung, die mit einer Variablen verknüpft ist, sind aber nicht darauf beschränkt.
Argumente zum Lags-Operator 266 umfassen gewöhnlich eine Input-Variable, die zu charakterisieren ist, die Anzahl vorhergehender Werte der Input-Variablen, die verwendet werden sollen, um die Variable zu verdichten, die Art des gewünschten charakteristischen Wertes, und eine Variable, um den zurückgegebenen charakteristischen Wert zu enthalten. Es sollte zur Kenntnis genommen werden, dass in einigen Ausführungsformen der Lags-Operator 266 angeordnet sein kann, mehr als einen charakteristischen Wert zu empfangen und zurückzugeben, der eine Variable verdichtet.
Die Operatoren 206 umfassen weiter einen „JoinHistogram"-Operator 270, der in der beschriebenen Ausführungsform verwendet werden kann, um Statistiken bezüglich einer Variablen über verschiedene Konten zu erzeugen. Das heißt, der JoinHistogram-Operator 270 analysiert die neuesten Werte, damit eine Input-Variable zu einem Histogramm verarbeitet wird. Während der Satz von Werten, der wie zuvor beschrieben unter Verwendung des Histogramm-Operators 262 analysiert worden ist, aus einem einzelnen Konto gewonnen wird, wird der Satz von Werten, der mit dem Histogramm-Operator 270 analysiert worden ist, aus unterschiedlichen Konten gewonnen. Es sollte zur Kenntnis genommen werden, dass im Allgemeinen die Argumente, die an den JoinHistogram-Operator 270 übergeben werden, dieselben sind, wie die Argumente, die an den Histogramm-Operator 270 übergeben werden, z. B. eine Input-Variable und eine Anzahl von Verzögerungen.
Ein „JoinSummarize"-Operator 278 hängt mit Verzögerungs-Operator 266 dadurch zusammen, dass der JoinSummarize Operator 278 eine Reihe von Werten zusammenfasst, die mit einer Variablen verknüpft sind. Während jedoch der Verzögerungs-Operator 266 die Werte zusammenfasst, die mit einem einzelnen Konto verknüpft sind, fasst der JoinSummarize-Operator 278 die Werte zusammen, die mit getrennten, aber gemeinsamen Konten verknüpft sind, z. B. verschiedenen Konten, die einem einzelnen Kunden gehören.
Der JoinSummarize-Operator 278 und der Verzögerungs-Operator 266 sind verknüpft; daraus folgt, dass die Argumente, die an den JoinSummarize-Operator 278 übergeben werden, im Allgemeinen dieselben sind, wie die Argumente, die an den Verzögerungs-Operator 266 übergeben werden. Jedoch können Optionen, die mit unterschiedlichen Argumenten verknüpft sind, zwischen dem Verzögerungs-Operator 266 und dem JoinSummarize-Operator 278 variiert werden. Beispielsweise können Optionen für ein Argument, das den charakteristischen Typ enthält, sowohl für den Verzögerungs-Operator 266 als auch für den JoinSummarize-Operator 278 wie zuvor erwähnt den Maximalwert einer Variablen, den Mindestwert einer Variablen, den Mittelwert einer Variablen und die Standardabweichung umfassen, die mit einer Variablen verknüpft sind. Während der JoinSummarize-Operator 278 mit mehr als einem Konto verknüpft ist, können charakteristische Typen für den JoinSummarize-Operator 278 darüber hinaus Charakteristiken, wie die Anzahl der Konten umfassen, die Non-Zero-Werte für eine Variable besitzen.
Wie zuvor behandelt, ist in der beschriebenen Ausführungsform die bevorzugte Mindestzahl von Operatoren 206, die verwendet werden, um effizient Input-Transaktionsdaten in im Wesentlichen jeden gewünschten Output zu verwandeln, sechzehn. Jedoch sind die sechzehn zuvor beschriebenen Operatoren für die Verwendung mit Input-Strömen fester Länge bestimmt, in denen sich bestimmte Daten an festen Positionen befinden. Mit anderen Worten, es sollen die sechzehn Operatoren auf Systeme angewendet werden, in denen Transaktionsdaten in Strömen von Standardlänge dargestellt sind. Innerhalb dieser Ströme liegen Zeichenketten, die bestimmte Arten von Daten betreffen, an bekannten Positionen, wie von Fachleuten geschätzt wird.
Für Ausführungsformen, in denen entweder die Stromlängen oder die Position von Daten oder beide innerhalb eines Stromes schwanken können, kann ein optionaler siebzehnter Operator in Verbindung mit den sechzehn Operatoren verwendet werden, die oben beschrieben werden. In der beschriebenen Ausführungsform ist der optionale siebzehnte Operator ein „Token"-Operator 278. Der Token-Operator 278 kann angeordnet sein, um die Datensatzlängen von Variablen und von Positionen von Variablen innerhalb eines Stromes zu kennzeichnen. Die Argumente, die an den Token-Operator 278 übergeben werden, umfassen im Allgemeinen den Namen einer Input-Variablen sowie ein „Token" oder einen Bezeichner für die Input-Variable. Das Token kann ein bestimmtes Zeichen sein, das, wenn es in einem Strom gefunden wird, bedeutet, dass die Zeichenkette, welche die Input-Variable betrifft, danach folgt. Es sollte zur Kenntnis genommen werden, dass für Ausführungsformen, in denen die Datensatzlänge der Input-Variablen unbekannt ist, ein zusätzlicher Token-Wert, der das Ende einer Zeichenkette kennzeichnet, als Argument zum Token-Operator 278 zugefügt werden kann.
Es sollte zur Kenntnis genommen werden, dass in einer Ausführungsform, der Gebrauch von mindestens fünf Operatoren ausreichend sein kann, um im Wesentlichen alle gewünschten Kenngrößen-Variablen zu erzeugen. Diese fünf Operatoren sind der DataBaseLog-Operator 214, der IndexRead-Operator 218, der atomarer Operator 222, der ArraySparse-Operator 242 und der Verzögerungs-Operator 266. Ein zusätzlicher Operator, z. B. der JoinSummarize-Operator 274, ist im Allgemeinen erforderlich, um Muster zu erzeugen, die eine Aggregation mehrerer Konten darstellen.
3 ist eine graphische Darstellung der Klassen, die durch einen Mustererzeugungsapparat in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung erkannt werden. Im Allgemeinen vertreten die Klassen Bereiche von Operatoren, die zuvor mit Bezug auf 2 beschrieben werden. Die Klassen sind so eingeteilt, dass durch Auswählen von Operatoren aus den Klassen und durch Anwenden der Operatoren einer bestimmten „Reihenfolge" folgend, die mit Bezug auf 4 nachfolgend beschrieben ist, im Wesentlichen jeder gewünschte Transaktions-Output erlangt werden kann. Mit anderen Worten wird durch Kombinieren von Operatoren, die aus den Klassen einer Vorrangbeziehung folgend ausgewählt werden, die mit den Klassen verknüpft ist, die Erzeugung im Wesentlichen jedes gewünschten Outputs ermöglicht, der für den Gebrauch in einem Risikoprognose- Modell geeignet ist.
In einer gegenwärtig bevorzugten Ausführungsform wird eine Gesamtmenge von fünf Klassen 304 bereit gestellt, umfassend eine „Datenbank-Datenstruktur"-Klasse 306, eine „atomare Umformungs"-Klasse 308, eine „Entity-Umformungs"-Klasse 310, eine „Zeitumformungs"-Klasse 312 und eine „Zusammenführungs-Operator"-Klasse 314. Einige der Klassen 304 können in Unterklassen 320 aufgeteilt werden. Beispielsweise kann die Entity-Umformungsklasse 310 in eine „einfache Umformungs"-Unterklasse 322 und in eine „komplexe Umformungs"-Unterklasse 324 eingeteilt werden, während die Zeit-Umformungsklasse 312 in eine „Integrations-/Glättungs-Umformungs"-Unterklasse 326 und in eine „Verzögerungs-Umformungs"-Unterklasse 328 eingeteilt werden kann.
Die Klassennummern 330 können mit Klassen 304 verknüpft sein. Beispielsweise ist die Datenbank-Datenstrukturklasse 306 mit der Klassennummer „1" 332 verknüpft, während die atomare Umformungsklasse 308 mit der Klassennummer „2" 334 verknüpft ist. Weiter ist Entity-Umformungsklasse 310 mit Klassennummer „3" 336 verknüpft, die Zeit-Umformungsklasse 312 ist mit Klassennummer „4" 338 verknüpft und die Zusammenführungs-Operator-Klasse 314 ist mit Klassennummer „5" 340 verknüpft. Es sollte zur Kenntnis genommen werden, dass hier und nachfolgend die Klassen 304 und die Klassennummern 330, die mit den Klassen 304 verknüpft sind, austauschbar verwendet werden.
Die Datenbank-Datenstrukturklasse 306, umfasst im Allgemeinen eine Untermenge von Operatoren 206, die sich auf Variablen beziehen, die in den Datenbanken gespeichert sein können. Die Untermenge von Operatoren 206 besteht aus dem Datenbank-Operator 210, dem DataBaseLag-Operator 214 und dem IndexRead-Operator 218. Die atomare Umformungsklasse 308 umfasst im Allgemeinen Operatoren 206, die das Erlangen von Daten aus Feldern betreffen, die in den ASCII-Dateien enthalten sind, wie zum Beispiel formatierte Transaktions-Protokoll-Dateien (FTL – Formatted Transaktion Log). Die Operatoren 206, die in der atomaren Umformungsklasse 308 enthalten sind, können verwendet werden, um gewünschte Informations-Bytes aus ASCII-Dateien zu segmentieren. Insofern sind die Operatoren 206, die in der atomaren Umformungsklasse 308 enthalten sind, der atomare Operator 222, der konstante Operator 226 und der optionale Token-Operator 278. Es sollte zur Kenntnis genommen werden, dass die Operatoren 206 in der Datenbank-Datenstrukturklasse 306 verwendet werden können, um auf permanente Variablen zu wirken, wie auch auf transiente und temporäre Variablen.
Die Entity-Umformungsklasse 310 kann wie zuvor erwähnt in die einfache Umformungs-Unterklasse 322 und in die komplexe Umformungs-Unterklasse 324 unterteilt werden. Im Allgemeinen bezieht die Entity-Umformungsklasse 310 eine Untermenge von Operatoren 206 ein, die verwendet werden können, um Variablen und Tabellen von einem Format zu einem anderen umzuwandeln. Die einfache Umformungs-Unterklasse 322 umfasst den Continuous-Operator 230 und den Fuzz-Operator 234, die beide typischerweise angeordnet sind, um eine einfache Variable in einer statischen Weise umzuwandeln. Alternativ umfasst die Komplexe Umformungs-Unterklasse 324 den ArraySparse-Operator 242 und den GeneralOperator-Operator 246, die im Allgemeinen zur Umwandlung verwendet werden. Im Allgemeinen können Operatoren 206, die in Entity-Umformungsklasse 310 enthalten sind, nur gegen transiente oder temporäre Werte wirken.
Die Zeit-Umformungsklasse 312 umfasst in der beschriebenen Ausführungsform eine Untermenge der Operatoren 206, die verwendet werden, um auf Datensätzen zu wirken, die mit einer Datenbank verknüpft sind. Die Datensätze verkörpern im Allgemeinen Zeitreihen von Transaktionsdaten. Eine „Integrations-/Glättungs-Umformungs"-Unterklasse 326 und eine „Verzögerungs-Umformungs"-Unterklasse 328 sind Unterklassen 320 der Zeit-Umformungsklasse 312. Die Integrations-/Glättungs-Umformungs-Unterklasse 326 umfasst Operatoren 206, die verwendet werden können, um auf Datenbank-Ereignis-Datensätze zu wirken, um z. B. Durchschnitte für Transaktionen zu berechnen, ohne alle vorhergehenden Transaktionen ausdrücklich zu speichern.
Der AlphaSmoothing-Operator 250 und der AlphaBetaSmoothing-Operator 254, die zuvor behandelt wurden, sind mit der Integrations-/Glättungs-Umformungs-Unterklasse 326 verknüpft. Die Operatoren 206, die mit der Verzögerungs-Umformungs- Unterklasse 328 verknüpft sind, sind angeordnet, um im Wesentlichen alle verfügbaren Daten zu verwenden, z. B. Ereignis-Datensätze, die eine bestimmte Art von Transaktion über einen gegebenen Zeitabschnitt so umfassen, dass ein Trend in den Daten festgestellt werden kann. Der Prognose-Operator 258, der Histogramm-Operator 262, und der Verzögerungs-Operator 266 sind im Allgemeinen mit der Verzögerungs-Umformungs-Unterklasse 328 verknüpft. Es sollte zur Kenntnis genommen werden, dass die Operatoren 206, die in der Zeit-Umformungsklasse 312 enthalten sind, nur angeordnet sind, auf transiente oder temporäre Werte zu wirken.
Im Allgemeinen werden Operatoren 206, die in der Zusammenführungs-Operator-Klasse 314 enthalten sind, verwendet, um Variablen über verschiedene Konten zu verknüpfen oder anders zu koppeln, die einen gemeinsamen Gesichtspunkt haben. Dieser gemeinsame Gesichtspunkt kann zum Beispiel ein gemeinsamer Besitzer der verschiedenen Konten sein. Im Wesentlichen werden die Operatoren 206, die mit der Zusammenführungs-Operator-Klasse 314 verknüpft sind, verwendet, um Variablen über verschiedene Konten zu aggregieren, um eine gesamte Darstellung der Variablen über die Zeit zu erzeugen. In der beschriebenen Ausführungsform umfasst die Zusammenführungs-Operator-Klasse 314 den JoinHistogram-Operator 270 und den JoinSummarize-Operator 274. Die Operatoren 206, die mit der Zusammenführungs-Operator-Klasse 314 verknüpft sind, sind so angeordnet, dass sie nur auf die transienten oder temporären Werte wirken können.
Mit Bezug auf 4 werden die Vorrangverhältnisse zwischen Klassen, d.h., die Klassen, die zuvor in Bezug auf 3 behandelt worden sind, gemäß einer Ausführungsform der vorliegenden Erfindung beschrieben. Ein Vorrangverhältnis spezifiziert die Reihenfolge, in der Operationen in den unterschiedlichen Klassen durchgeführt werden können. Das heißt, ein Vorrangverhältnis bestimmt, welche Operatoren Input für andere Operatoren zur Verfügung stellen können.
Es sollte zur Kenntnis genommen werden, dass alle Operatoren Werte übergeben, z. B. permanente oder temporäre Werte. Solche Werte können skalare, Vektor- oder Matrix-Werte sein. Insofern repräsentieren Vorrangverhältnisse, die in 4 durch Pfeile angezeigt werden, den Vorrang der Operator-Operationen und beschreiben zusätzlich den Fluss der Datenwerte zwischen Operatoren. In einer Ausführungsform sind die Datenwerte Ganzzahlen, Gleitkommazahlen und Zeichenketten.
Das Vorrangzustandsdiagramm 402 umfasst Darstellungen der Klasse „1" 408, d.h. der Datenbank-Datenstrukturklasse, Klasse „2" 410, d.h. der atomaren Umformungsklasse, Klasse „3" 412, d.h. der Entity-Umformungsklasse, Klasse „4" 414, d.h. der Zeit-Umformungsklasse und Klasse „5" 416, d.h. der Zusammenführungs-Operator-Klasse. Das Vorrangverhältnis zwischen Klassen wird im Allgemeinen durch Pfeile dargestellt, wie zum Beispiel Pfeil 420 zwischen Klasse „1" 408 und Klasse „ 2" 410. Wie zuvor erwähnt, kann im Wesentlichen jede gewünschte Charakteristik aus den Transaktionsdaten gewonnen werden, indem man Operatoren unter Verwendung des Vorrangverhältnisses kombiniert, das durch das Vorrangzustandsdiagamm 402 umrissen wird.
Wie durch den Pfeil 420 angezeigt, kann eine Operation in der Klasse „1" 408 einer Operation in der Klasse „2" 410 vorausgehen. Zum Beispiel kann ein Wert, z. B. ein Wert im ASCII-Format, gewonnen aus einer Datenbank, in einen numerischen Wert durch eine Operation umgewandelt werden, die mit Klasse „ 2" 410 verknüpft ist. Mit anderen Worten, es kann ein Wert, der aus einer Datenbank gewonnen wird, als Argument in einer Operation verwendet werden, die mit Klasse „2" 410 verknüpft ist. Der Pfeil 420 zeigt auch an, dass eine Operation der Klasse „2" 410 einer Operation in der Klasse „1" 408 vorausgehen kann. Insofern zeigt ein weiteres Verhältnis, das durch den Pfeil 420 spezifiziert wird, in einer Ausführungsform an, dass ein Wert, der von einer atomaren Umwandlung erzeugt wird, in eine Datenbank gespeichert werden kann.
Ein Pfeil 422 spezifiziert ein Vorrangverhältnis zwischen Klasse „1" 408 und Klasse „3" 412. Das Verhältnis, das durch den Pfeil 422 bestimmt ist, zeigt an, dass die Operationen, die mit Klasse „1" 408 verknüpft sind, den Operationen direkt vorausgehen können, die mit Klasse „3" 412 verknüpft sind, und dass die Operationen, die mit Klasse „3" 412 verknüpft sind, den Operationen vorausgehen können, die mit Klasse „1" 408 verknüpft sind. Der Pfeil 422 deutet an, dass Daten aus einer Datenbank abgefragt und von einer Entity-Umwandlung bearbeitet werden können. Beispielsweise kann ein atomarer Wert, der aus einer Datenbank abgefragt wird, in ein gewünschtes Format abgebildet werden, das mit einem Risikoprognose-Modell verknüpft ist. Der Pfeil 422 zeigt auch, dass auf Daten, die durch eine Operation bearbeitet werden, die mit Klasse „3" 412 verknüpft ist, im Allgemeinen eine Operation folgen kann, die mit Klasse „1" 408 verknüpft ist, z. B. können Daten, die durch eine Operation umgewandelt werden, die mit Klasse „3" 412 verknüpft ist, unmittelbar in eine Datenbank gespeichert werden.
Ein Pfeil 424 zeigt an, dass Klasse „3" 424 auf sich wieder eintrittsvariant ist. Mit anderen Worten, eine Operation kann in der Klasse „3" 424 einer anderen Operation in der Klasse „3" 424 vorausgehen. Beispielsweise kann der ArraySparse-Operator dem Continuous-Operator direkt vorausgehen, wenn der ArraySparse-Operator verwendet wird, um einen Risiko-Wert zu finden, der dann vom Continuous-Operator als Skalierungsfaktor verwendet wird.
Ein Pfeil 426 deutet an, dass Operatoren der Klasse „2" 410 Operatoren der Klasse „3" 412 direkt vorausgehen können. In einer Ausführungsform kann der atomare Operator, der ein Teil der Klasse „2" 410 ist, verwendet werden, um ein Datenfeld aus einer Datei zu lesen, die als Input-Argument für einen Operator bereit gestellt wird, der ein Teil der Klasse „3" 412 ist, z. B. der ArraySparse-Operator.
Das Vorrangverhältnis zwischen Klasse „3" 412 und Klasse „4" 414 wird bestimmt durch einen Pfeil 428, der anzeigt, dass, während Operatoren, die in Klasse „3" 412 enthalten sind, Operatoren vorausgehen können, die in Klasse „4" 414 enthalten sind, die Operatoren, die in Klasse „4" 414 enthalten sind, auch Operatoren vorausgehen können, die in Klasse „3" 412 enthalten sind. Mit anderen Worten können Entity-Umwandlungen und Zeitumwandlungen in jeder Reihenfolge auftreten. Ein Beispiel einer Operation in Klasse „3" 412, die einer Operation in Klasse „4" 414 vorausgeht, bezieht ein, den Continuous-Operator zu verwenden, um Daten einzustufen, die dann als Argument für den AlphaSmoothing-Operator so zur Verfügung gestellt werden, dass der geglättete Wert der eingestuften Daten zurückgegeben wird. Alternativ kann ein Beispiel einer Operation in Klasse „4" 414, die einer Operation in Klasse „3" 412 vorausgeht, bedeuten, den ArraySparse-Operator mit Resultaten aufzurufen, die mit dem Histogramm-Operator gewonnen werden, um ein Feld in einem Array zu finden, das die Resultate abbildet, die mit dem Histogramm-Operator erreicht werden.
Wie es der Fall für Klasse „3" 412 war, so ist Klasse „4" 414, wie durch einen Pfeil 430 gezeigt wird, ebenfalls auf sich wiedereintrittsvariant. Folglich kann ein Operator in der Klasse „4" 414 einem weiteren Operator in der Klasse „4" 414 vorausgehen, z. B. kann der Verzögerungs-Operator verwendet werden, einen Wertiebereich zu gewinnen, der vom Histogramm-Operator verwendet wird.
Während Operatoren der Klasse „4" 414 gewöhnlich nicht direkt Operatoren der Klasse „2" 410 vorausgehen, können in der beschriebenen Ausführungsform Operatoren der Klasse „2" 410 direkt Operatoren der Klasse „4" 414 vorausgehen, wie von einem Pfeil 432 angezeigt. Dies deutet an, dass die Resultate, die mit atomaren Umwandlungen erreicht werden, als Rechengrößen für eine Zeitumwandlung verwendet werden können. Zum Beispiel kann der Wert einer konstanten Variablen, z. B. eine Vertrauensgrenze einer Prognose, definiert mit dem Constant-Operator als Argument für den Prognosenoperator zur Verfügung gestellt werden.
Ein Pfeil 434 spezifiziert ein Vorrangverhältnis zwischen Klasse „1" 408 und Klasse „4" 414. Das Vorrangverhältnis, wie durch den Pfeil 434 definiert, zeigt an, dass Operationen, die mit Klasse „1" 408 verknüpft sind, den Operationen direkt vorausgehen können, die mit Klasse „4" 414 verknüpft sind, und umgekehrt können Operationen, die mit Klasse „4" 414 verknüpft sind, den Operationen direkt vorausgehen, die mit Klasse „1" 408 verknüpft sind. Der Pfeil 434 deutet an, dass Daten aus einer Datenbank geholt werden und von einer Zeitumwandlung bearbeitet werden können. Beispielsweise kann ein atomarer Wert, der aus einer Datenbank abgefragt wird, auf eine solche Operation wie eine Prognose abgebildet und in ihr verwendet werden. Das heißt, eine Prognose kann mit den Daten durchgeführt werden, die aus einer Datenbank abgefragt werden. Der Pfeil 434 deutet auch an, dass Daten, auf die eine Operation zugehörig zu Klasse „4" 414 wirkt, sofort unter Verwendung einer Datenbank-Datenstrukturoperation, d.h. einer Operation, die mit Klasse „1" 408 verknüpft ist, bearbeitet werden können.
Klasse „4" 414 hängt mit Klasse „5" 416 zusammen, wie durch einen Pfeil 436 dargestellt. Insbesondere, wie durch den Pfeil 436 dargestellt, ist der Vorrang zwischen Klasse „4" 414 und „5" 416 so, dass Operatoren in jeder der beiden Klassen Operatoren in der anderen Klasse direkt vorangehen können. Zum Beispiel kann der Histogramm-Operator, der ein Teil der Klasse „4" 414 ist, entweder dem JoinHistogram-Operator, der ein Teil der Klasse „5" 416 ist, direkt vorausgehen oder direkt folgen.
Das Vorrangverhältnis, das durch einen Pfeil 438 dargestellt wird, deutet an, dass die Operatoren, die mit Klasse „1" 408 verknüpft sind, den Operatoren vorausgehen können, die mit Klasse „5" 416 verknüpft sind. Mit anderen Worten, zeigt der Pfeil 438 an, dass Daten, die aus einer Datenbank eingeholt werden, direkt von einem Operator bearbeitet werden. können, der mit Klasse „5" 416, d.h. entweder dem JoinHistogram-Operator oder dem JoinSummarize-Operator, verknüpft ist. Das Vorrangverhältnis, das durch den Pfeil 438 dargestellt ist, impliziert auch, dass Operatoren, die mit Klasse, „5" 416 verknüpft sind, den Operatoren vorausgehen können, die mit Klasse "1" 408 verknüpft sind.
Das Vorrangverhältnis zwischen Klasse „2" 410 und Klasse „5" 416 ist durch einen Pfeil 440 dargestellt. Die Operatoren, die mit Klasse „2" 410 verknüpft sind, können direkt den Operatoren vorausgehen, die mit Klasse „5" 416 verknüpft sind, oder sie dienen jenen als Argumente, d.h. eine atomare Umwandlung kann direkt einem Zusammenführungs-Operator vorausgehen. Beispielsweise kann ein konstanter Wert, der mit dem konstanten Operator erzeugt wird, z. B. die Zeit, über die eine Variable aufsummiert wird, als Argument verwendet werden, das dem JoinSummarize-Operator übergeben wird.
Das Vorrangverhältnis zwischen Klasse „3" 412 und Klasse „5" 416 wird angezeigt durch einen Pfeil 442, der zeigt, dass Operatoren in der Klasse „3" 412 Operatoren in der Klasse „5" 416 vorausgehen können, und dass umgekehrt Operatoren in der Klasse „5" 416 Operatoren in der Klasse „3" 412 vorausgehen können. Zum Beispiel kann der GeneralOperator-Operator, der mit Klasse „3" 412 verknüpft ist, ausgeführt werden, um eine Variable umzuwandeln, die dann als Argument für den JoinSummarize-Operator verwendet werden kann, der mit Klasse „5" 416 verknüpft ist. Alternativ können Resultate der Ausführung des JoinSummarize-Operators vom GeneralOperator- Operator bearbeitet werden.
Um das Vorrangverhältnis zwischen Klassen besser zu veranschaulichen, wird ein grundlegendes Beispiel einer Datenanalyse, die nach Vorrangzustandsdiagramm 402 durchgeführt wird, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung beschrieben. Es sollte zur Kenntnis genommen werden, dass dieses grundlegende Beispiel im Allgemeinen veranschaulichen soll, wie Operatoren und Klassen miteinander in Beziehung stehen. Insofern werden spezifische Einzelheiten, wie die tatsächliche Syntax der Argumente, die den Operatoren übergeben werden, nicht beschrieben.
Zum Beispiel kann, wenn das Konkursrisiko eines bestimmten Kontoinhabers bewertet wird, ein Geldinstitut bestimmte Arten von Transaktionen, d.h. bewertbare Transaktionen, und die Frequenz der verschiedenen Arten von Transaktionen überwachen. Zum Beispiel kann, wenn das Volumen und die finanzielle Höhe von Transaktionen zur Bargeld-Abhebung sich drastisch über dem Kurs eines spezifizierten Zeitabschnitts erhöhen, solche Aktivität mit einem verhältnismäßig hohen Konkursrisiko verbunden sein. Insofern kann ein Geldinstitut wünschen, die Anzahl von Transaktionen zur Bargeld-Abhebung zu überwachen, die ein Kontoinhaber/eine Kontoinhaberin mit seiner oder ihrer Bankkarte über einen spezifizierten Zeitabschnitt vorgenommen hat.
Um die Transaktionen zur Bargeld-Abhebung zu überwachen, die auf einem Konto von einem Kunden innerhalb eines spezifizierten Zeitabschnitts durchgeführt werden, wird ein Operator, der mit Klasse „1" 408 verknüpft ist, d.h. die Datenbank-Datenstrukturklasse, aufgerufen. In der beschriebenen Ausführungsform wird der DataBaseLag-Operator aufgerufen. Wie zuvor beschrieben, wird der DataBaseLag-Operator im Allgemeinen dazu verwendet, Positionen innerhalb einer Datenbank zu identifizieren, in der Verzögerungen von Variablen gespeichert werden können. Die Argumente, die dem DataBaseLag-Operator übergeben werden, können den Namen der Variablen, in der Verzögerungen gespeichert werden, die Position in der Datenbank, in der die Variable gespeichert wird, die Anzahl der zu speichernden Verzögerungen, den Zeitabschnitt, über den die Variable verzögert wird, den Namen der Datenbank, in der die Variable gespeichert wird, und den Variablentyp umfassen.
Im Allgemeinen wird der Name der Variable, in der Verzögerungen gespeichert werden, durch den entsprechenden Handelsklassencode identifiziert, und der Zeitabschnitt, über den die Variable verzögert ist, kann so spezifiziert werden, dass z. B. auf jede über eine Woche durchgeführte Transaktion zugegriffen werden kann. In der beschriebenen Ausführungsform kann angenommen werden, dass der spezifizierte Zeitabschnitt eine Woche ist und dass sich die Variable auf Barentnahmen bezieht.
Sobald der DataBaseLags-Operator aufgerufen wird, wird der atomare Operator, der ein Teil der Klasse „2" 410 ist, aufgerufen, d.h. dem Vorrangverhältnis, das durch Pfeil 420 angezeigt wird, wird gefolgt, um die passenden Daten von der Position zu lesen, die innerhalb der Datenbank identifiziert wird. Mit anderen Worten wird der atomare Operator verwendet, um die Zeichenkette zu analysieren, welche die Transaktionen enthält, die über die letzte Woche vom Kontoinhaber durchgeführt wurden.
Sobald die relevanten Informationen eingeholt worden sind, wird der Histogramm-Operator, der mit Klasse „4" 414 verknüpft ist, in der beschriebenen Ausführungsform aufgerufen. Das Vorrangverhältnis zwischen Klasse „2" 410 und Klasse „4" 414 wird durch den Pfeil 432 bestimmt. Der Histogramm-Operator kann so verwendet werden, dass die Daten, die über den atomaren Operator gewonnen werden, im Wesentlichen sortiert werden können. Das heißt, der Histogramm-Operator kann verwendet werden, um die Statistiken bezüglich Barentnahmen zu erzeugen. Zum Beispiel kann der Histogramm-Operator verwendet werden, um die Art der Barentnahmen zu identifizieren, z. B. Barentnahmen, die einen gegebenen Wert übersteigen, die am häufigsten über dem Kurs der letzten Woche gemacht wurden. Es sollte zur Kenntnis genommen werden dass, für den Fall, dass die Frequenz dieselbe für mehr als eine Art Barentnahmen, z. B. für zwei unterschiedliche Arten von Barentnahmen, ist, der Histogramm-Operator dann im Allgemeinen das erste Auftreten von einer der Arten der Barentnahme als der Art des Erwerbes mit der höchsten Frequenz wählt.
Der Histogramm-Operator kann mit einem Argument aufgerufen werden, das eine Verzögerungstiefe spezifiziert. Diese Verzögerungstiefe kann verwendet werden, um die Anzahl von Barentnahmen eines bestimmten Betrags zu spezifizieren, zum Beispiel, die als hochfrequente Art von Barentnahme betrachtet wird. Zum Beispiel kann eine Verzögerungstiefe von fünf andeuten, dass die Anzahl, wie oft eine bestimmte Art Barentnahme getätigt worden ist, erst fünf überschreiten muss, bevor diese Art der Barentnahme als eine Art Barentnahme betrachtet wird, die häufig getätigt wird.
Nachdem die Art der Barentnahme identifiziert ist, die am häufigsten getätigt wird, kann in der beschriebenen Ausführungsform der ArraySparse-Operator aufgerufen werden, um ein Risiko zu kennzeichnen, das mit der am häufigsten getätigten Barentnahmeart verknüpft ist. Der ArraySparse-Operator kann direkt aufgerufen werden, nachdem der Histogramm-Operator aufgerufen wurde, wegen des Vorrangverhältnisses, bestimmt durch den Pfeil 428 zwischen Klasse „ 3" 412, mit welcher der ArraySparse-Operator verknüpft ist, und Klasse „4" 414, mit welcher der Histogramm-Operator verknüpft ist. Es sollte zur Kenntnis genommen werden, dass der ArraySparse-Operator im Allgemeinen verwendet werden kann, um einen Risikowert mit der Art der Barentnahme zu verknüpfen, die am häufigsten auftritt, indem er auf ein Array von Risikowerten zugreift. Dieser Risikowert kann dann einem Risikoprognose-Modell übergeben werden, wie oben erwähnt.
Es sollte zur Kenntnis genommen werden, dass für den Fall, dass ein Kontoinhaber mehr als ein Konto besitzt, z. B. mehr als eine Bankkarte hat, der Risikowert, der mit der Art der Barentnahme verknüpft ist, die am häufigsten auftritt, für jedes Konto festgestellt werden kann. In diesem Fall kann der JoinHistogram-Operator, der mit Klasse „5" 416 verknüpft ist, aufgerufen werden, um die allumfassende Art der Barentnahme zu bestimmen, die am häufigsten über alle betreffenden Konten hinweg auftritt, oder über die Konten, die einem Kontoinhaber gehören. Dann kann ein Risikowert für diese Art der Barentnahme mit dem ArraySparse-Operator festgestellt werden.
Obgleich nur einige Ausführungsformen der vorliegenden Erfindung beschrieben worden sind, sollte verstanden werden, dass die vorliegende Erfindung in vielen anderen spezifischen Formen ausgeführt werden kann, ohne den Umfang der Erfindung zu verlassen. Obgleich die Mindestzahl der notwendigen Operatoren in fünf Klassen aufgeteilt worden ist, sollte es zum Beispiel zur Kenntnis genommen werden, dass die Anzahl der Klassen variieren kann. In einigen Fällen können Klassen kombiniert werden. In anderen Fällen können Klassen geteilt werden, z. B. können die einfache Umformungs-Unterklasse und die komplexe Umformungs-Unterklasse der Entity-Umformungsklasse als separate Klassen betrachtet werden.
Obgleich ein allgemeines Vorrangverhältnis für die Operatoren beschrieben worden ist, die innerhalb der Klassen enthalten sind, sollte weiterhin zur Kenntnis genommen werden, dass es in einigen Fällen sein kann, dass es möglicherweise für einen bestimmten Operator in einer Klasse nicht angebracht ist, einem bestimmten Operator in einer anderen Klasse direkt vorauszugehen. Jedoch ist in solchen Fällen mindestens ein Operator in einer gegebenen Klasse für das Vorausgehen eines Operators in einer anderen Klasse anwendbar, wie vom Vorrangverhältnis spezifiziert.
Obgleich die Operatoren so beschrieben worden sind, dass sie bestimmte Argumente entgegennehmen, sollte zur Kenntnis genommen werden, dass die Argumente weit variiert werden können, ohne vom Umfang der vorliegenden Erfindung abzuweichen. Beispielsweise kann der IndexRead-Operator ein statistisches Argument umfassen, das verwendet werden kann, um die Zahl der Statistiken zu bestimmen, die von einer Indextabelle eingelesen werden sollen, d.h. die Zahl der Statistiken, die mit jedem Parameter verknüpft sind, der von der Indextabelle gelesen wird. Daher sind die vorliegenden Beispiele veranschaulichend und nicht einschränkend zu betrachten, wobei die Erfindung nicht auf die hierin gegebenen Einzelheiten zu begrenzen ist, sondern innerhalb des Bereichs der angefügten Ansprüche abgewandelt werden kann.

Claims

Computer-implementiertes Verfahren zum Umformen bewertbarer Transaktionsdaten (104) in eine Kenngrößen-Variable (114), nutzbar zum Beurteilen von Finanzrisiken, wobei das Verfahren umfasst: Anfordern der bewertbaren Transaktionsdaten (104) von einer Datenquelle; gekennzeichnet durch die Schritte: Identifizieren einer Reihe vordefinierter Operationsklassen (306, 308, 310, 312, 314), die in einer vordefinierten Rangfolge (402) angeordnet sind, wobei die Reihe vordefinierter Operationsklassen höchstens fünf Operationsklassen umfasst, wobei die fünf Operationsklassen eine Datenstrukturklasse, eine atomare Umformungsklasse, eine Entity-Umformungsklasse, eine Zeit-Umformungsklasse und eine Zusammenführungs-Operator-Klasse sind; Auswählen einer Reihe von Operationen (202) aus der vordefinierten Reihe von Operationsklassen (306, 308, 310, 312, 314); und Anwenden einer Reihe von Operationen (202) auf die bewertbaren Transaktionsdaten (104) zum Umformen der bewertbaren Transaktionsdaten (104) in die Kenngrößen-Variable (114), wobei jede Operation aus der Reihe von Operationen (202) in einer Reihenfolge angewendet wird, die auf der vordefinierten Rangfolge (402) der Klasse (306, 308, 310, 312, 314) beruht, die mit der jeweiligen Operation verknüpft ist, wodurch die Kenngrößen-Variable (114) aus den bewertbaren Transaktionsdaten (104) extrahiert wird.
Computer-implementiertes Verfahren nach Anspruch 1, wobei der Schritt des Anwendens einer Reihe von Operationen (202) umfasst: Anwenden zuerst einer Datenstrukturoperation (306), die mit der Datenstrukturklasse (332) verknüpft ist; Anwenden einer atomaren Umformungsoperation (308), die mit der atomaren Umformungsklasse (334) verknüpft ist, unmittelbar nach dem Anwenden der Datenstrukturoperation (306), die mit der Datenstrukturklasse (332) verknüpft ist; Anwenden einer Entity-Umformungsoperation (310), die mit der Entity-Umformungsklasse (336) verknüpft ist, unmittelbar nach dem Anwenden der atomaren Umformungsoperation (308), die mit der atomaren Umformungsklasse (334) verknüpft ist; Anwenden einer Zeitumformungsoperation (312), die mit der Zeitumformungsklasse (338) verknüpft ist, unmittelbar nach dem Anwenden der Entity-Umformungsoperation (310), die mit der Entity-Umformungsklasse (336) verknüpft ist; und Anwenden einer Zusammenführungsoperator-Operation (340), die mit der Zusammenführungsoperator-Klasse verknüpft ist, unmittelbar nach dem Anwenden der Zeitumformungsoperation (312), die mit der Zeitumformungsklasse (338) verknüpft ist.
Computer-implementiertes Verfahren nach Anspruch 1 oder 2, wobei die Kenngrößen-Variable zur Nutzung in einem Risikoprognose-Modell konfiguriert ist, wobei das Verfahren weiterhin umfasst: Bereitstellen der Kenngrößen-Variable (114) für das Risikoprognose-Modell (118) zum Beurteilen eines finanziellen Risikos.
Computer-implementiertes Verfahren nach Anspruch 1, 2 oder 3, weiterhin umfassend: Implementieren eines Risikoprognose-Modells (116) mit der Kenngrößen-Variablen (114); und Beurteilen eines Kreditrisikos, eines Betrugsrisikos oder eines Konkursrisikos auf der Grundlage eines Ergebnisses der Implementierung des Risikoprognose-Modells (116).
Computer-implementiertes Verfahren nach jedem der vorhergehenden Ansprüche, wobei die Kenngrößen-Variable weiterhin zur Nutzung in einem Transaktions-Bewertungsprozess konfiguriert ist, der mit einem Risikoprognose-Modell (116) verknüpft ist, wobei das Verfahren weiterhin umfasst: Bereitstellen der Kenngrößen-Variablen (114) für den Transaktions-Bewertungsprozess (118).
Computer-implementiertes Verfahren nach jedem der vorhergehenden Ansprüche, wobei die bewertbaren Transaktionsdaten (104) Teil eines hochvolumigen Datenstroms sind.
Computer-implementiertes Verfahren nach jedem der vorhergehenden Ansprüche, wobei die Reihe von Operationen (202) im Wesentlichen in Echtzeit ausgeführt wird.
Computer-implementiertes Verfahren nach jedem der vorhergehenden Ansprüche, wobei: Die Datenstrukturklasse (332) mindestens eine Operation (210, 214, 218) umfasst, die dafür angeordnet ist, die Information auf eine Datenbank zu beziehen; die atomare Umformungsklasse (334) mindestens eine Operation (222, 226, 278) umfasst, die dafür angeordnet ist, die Information von einem ersten Format in ein atomares Format umzuformen; die Entity-Umformungsklasse (336) mindestens eine Operation (230, 234, 242, 246) umfasst, die dafür angeordnet ist, die Information vom atomaren Format in ein zweites Format umzuformen; die Zeit-Umformungsklasse (338) mindestens eine Operation (250, 254, 258, 262, 266) umfasst, die dafür angeordnet ist, unter Verwendung der Information Berechnungen durchzuführen; und die Zusammenführungs-Operator-Klasse (340) mindestens eine Operation (270, 274) umfasst, die dafür angeordnet ist, die Information zu zusätzlicher Information in Beziehung zu setzen.
Computer-implementiertes Verfahren nach Anspruch 8, weiterhin umfassend: Ausführen einer ersten Operation (210, 214, 218) in der ersten Klasse (332); Ausführen einer ersten Operation (222, 226, 278) in der zweiten Klasse (334) unmittelbar nach Ausführen der ersten Operation (210, 214, 218) in der ersten Klasse (332); und Ausführen mindestens einer zweiten Operation (210, 214, 218) in der ersten Klasse (332), einer ersten Operation (230, 234, 242, 246) in der dritten Klasse (336), einer ersten Operation (250, 254, 258, 262, 266) in der vierten Klasse (338), oder einer ersten Operation (270, 274) in der fünften Klasse (340), unmittelbar nach Ausführen der ersten Operation (222, 226, 278) in der zweiten Klasse (334), wie durch die Rangfolge spezifiziert.
Computer-implementiertes Verfahren nach Anspruch 8, weiterhin umfassend: Ausführen einer ersten Operation (210, 214, 218) in der ersten Klasse (332); Ausführen einer ersten Operation (230, 234, 242, 246) in der dritten Klasse (336) unmittelbar nach Ausführen der ersten Operation (210, 214, 218) in der ersten Klasse (332); und Ausführen einer zweiten Operation (210, 214, 218) in der ersten Klasse (332), einer zweiten Operation (230, 234, 242, 246) in der dritten Klasse (336), einer ersten Operation (250, 254, 258, 262, 266) in der vierten Klasse (338), oder einer ersten Operation (270, 274) in der fünften Klasse (340), unmittelbar nach Ausführen der ersten Operation (230, 234, 242, 246) in der dritten Klasse (336), wie durch die Rangfolge spezifiziert.
Computer-implementiertes Verfahren nach jedem der vorhergehenden Ansprüche, weiterhin umfassend: Einspeisen der Kenngrößen-Variable in den Modellentwicklungsprozess, um ein Risikoprognose-Modell zu erzeugen.
Mustererzeugungsmechanismus (106), angeordnet für das Umformen einer gegebenen Transaktion in eine Kenngrößen-Variable (114), wobei die gegebene Finanztransaktion mit einem Datenstrom (104) verknüpft ist, der mindestens ein Datenfeld umfasst, wobei die Kenngrößen-Variable mit einem Modellierungsprozess verknüpft ist, wobei der Mustererzeugungsmechanismus (106) umfasst: eine erste Klasse (332), die mindestens eine Operation (210, 214, 218) umfasst, dafür angeordnet, um das Datenfeld auf eine Datenbank (110) zu beziehen; eine zweite Klasse (334), die mindestens eine Operation (222, 226, 278) umfasst, dafür angeordnet, um das Datenfeld aus einem ersten Format in ein atomares Format umzuformen; eine dritte Klasse (336), die mindestens eine Operation (230, 234, 242, 246) umfasst, dafür angeordnet, um das Datenfeld vom atomaren Format in ein zweites Format umzuformen; eine vierte Klasse (338), die mindestens eine Operation (250, 254, 258, 262, 266) umfasst, dafür angeordnet, um unter Verwendung des Datenfelds Berechnungen durchzuführen; eine fünfte Klasse (340), die mindestens eine Operation (270, 274) umfasst, dafür angeordnet, um das Datenfeld mit weiterer Information in Beziehung zu setzen; und einen Code (108), der die Kenngrößen-Variable (114) erzeugt, unter Verwendung von mindestens einem des Folgenden: der mindestens einen Operation (210, 214, 218) in der ersten Klasse (332), der mindestens einen Operation (222, 226, 278) in der zweiten Klasse (334), der mindestens einen Operation (230, 234, 242, 246) in der dritten Klasse (336), der mindestens einen Operation (250, 254, 258, 262, 266) in der vierten Klasse (338), und der mindestens einen Operation (270, 274) in der fünften Klasse (340), wobei die erste Klasse (408), die zweite Klasse (410), die dritte Klasse (412), die vierte Klasse (414) und die fünfte Klasse (416) durch ein Vorrang-Verhältnis in Verbindung stehen.
Mustererzeugungsmechanismus nach Anspruch 12, wobei das Vorrang-Verhältnis (420) dafür angeordnet ist, um die mindestens eine Operation (210, 214, 218) in der ersten Klasse (410) zu ermöglichen, die der mindestens einen Operation (222, 226, 278) in der zweiten Klasse vorausgeht; das Vorrang-Verhältnis (426) dafür angeordnet ist, um die mindestens eine Operation (210, 214, 218) in der ersten Klasse (410) zu ermöglichen, die der mindestens einen Operation (222, 226, 278) in der dritten Klasse (414) vorausgeht; das Vorrang-Verhältnis (432) dafür angeordnet ist, um die mindestens eine Operation (210, 214, 218) in der ersten Klasse (410) zu ermöglichen, die der mindestens einen Operation (250, 254, 258, 262, 266) in der vierten Klasse (414) vorausgeht; und das Vorrang-Verhältnis dafür angeordnet ist, um die mindestens eine Operation in der ersten Klasse zu ermöglichen, die der mindestens einen Operation in der fünften Klasse vorausgeht.
Mustererzeugungsmechanismus nach jedem der Ansprüche 11 bis 13, wobei die Kenngrößen-Variable dafür angeordnet ist, als Input für einen Modellentwicklungsprozess zu dienen, um ein Risikoprognose-Modell zu erzeugen.
Mustererzeugungsmechanismus nach jedem der Ansprüche 11 bis 14, wobei die Kenngrößen-Variable dafür angeordnet ist, als Input für ein Risikoprognose-Modell zu dienen, um Finanzrisiken zu beurteilen.
Mustererzeugungsmechanismus nach Anspruch 15, wobei die gegebene Transaktion mit einer ersten Entity verknüpft ist und das Risikoprognose-Modell (118) dafür angeordnet ist, ein Kreditrisiko, ein Betrugsrisiko oder ein Konkursrisiko für die erste Entity auf der Grundlage der gegebenen Transaktion zu beurteilen.
Mustererzeugungsmechanismus nach Anspruch 11, wobei die Kenngrößen-Variable dafür angeordnet ist, als Input für einen Transaktionsbewertungsprozess (118) zu dienen, um ein Finanzrisiko zu beurteilen.