Das Bild im Wettbewerb der Finanzdienstleister ist bedingt durch den ständigen Wandel und Fortschritt der Kommuni- kationstechnik sowie durch die damit verbundene Transparenz und Vergleichbarkeit einzelner Finanzdienstleistungen über Veränderungen im Kundenverhalten zunehmend durch die direkte Fokussierung auf den Endkunden geprägt. Auf der Kundenseite überwiegt der Wunsch, mit bestehenden Zahlungs- systemen händlerübergreifende Bestell-und Zahlungsvorgänge sowie weitere Zusatzdienstleistungen abwickeln zu können.

Zur Differenzierung der Finanzdienstleister aus der Sicht des Endkunden spielt deshalb insbesondere die Pflege der Kundenbeziehung und deren Historie, die Füllung von Bedarfslücken im Funktionsumfang der Finanzdienstleistungen sowie die Stückkosten und der Service eine zentrale Rolle.

Dementsprechend werden Finanzdienstleistungen, statt sie direkt über Filialbanken anzubieten, zunehmend im Direkt- vertrieb gemakelt.

Aus der IPC (Internationale Patentklassifikation) sind innerhalb der Klasse G07F selbstkassierende und ähnliche Geräte bekannt, wobei speziell unter G07F 19/00 voll- ständige Banksysteme und Bank-Transaktions-Geräte klassi-

fiziert sind. Die Druckschrift DT 2559136 A1 offenbart eine Vorrichtung für ein vollautomatisches Banksystem zum Ab- wickeln von Bankgeschäften. Dazu wird vom Kunden ein geeig- neter Kodeträger, bspw. eine Speicherkarte, in ein als Fernbankschalter dienendes Terminal eingeführt, dieser auf Echtheit überprüft und schließlich eine von mehreren verschiedenen Bankgeschäften ausgewählt. Die Druckschrift DE 4333388 Al offenbart die Möglichkeit, mit Hilfe einer als Multifunktionskarte ausgeführten Chipkarte verschiedene Finanztransaktionen der kontoführenden Bank sicher zu tätigen. Dazu führt der Kunde diese Multifunktionskarte in ein mit der EDVA der Bank verbundenes Terminal ein. Dabei werden bezüglich der getätigten Transaktion sichere Transaktionsdaten über Verschlüsselungsroutinen berechnet und von der Gegenseite überprüft. Aus historischen Gründen existieren eine Vielzahl verschiedener anbieterabhängige Standards für die Ansprache von Chipkarten. Die Druck- schrift WO 97/05582 stellt deshalb ein System vor, bei welchem ein einheitliches systemunabhängies Kundenterminal über eine Online-Verbindung mit einem Basisterminal ver- bunden ist, welches eine Vielzahl derartiger spezieller Chipkartenterminalmodule beinhaltet. Nachteilig bei der- artigen Verfahren ist, daß ein spezielles, im Verant- wortungsbereich der Bank liegendes Terminal als Fern- bankschalter verwendet werden muß, sowie das Programmodul des Terminals speziell an die über die Karte ausführbare Finanztransaktion und die kontoführende Bank angepaßt sein muß.

Es ist z. B. aus der Druckschrift DE 0542298 A2 bekannt, verschiedene Dienstleistungen mittels eines Heimrechners

online auszuführen. Die nur virtuell erreichbare Gegenseite bildet dazu eine virtuelle Filiale aus, bspw. als vir- tuelles Reisebüro, virtuelle Bankfiliale etc. Dabei kann die Online-Datenverbindung sowohl in geschlossen Netzen wie über BTX bei T-ONLINE oder in offenen Netzen wie im Internet erfolgen. Für virtuelle Finanzdienstleistungen sind besondere Sicherheitsanforderungen zu stellen, da in diesem Bereich die kriminelle Energie besonders hoch ist.

Deswegen wurde im Hinblick auf die gebotene Sicherheit für Deutschland mit dem HBCI (Homebanking Computer Interface) ein spezieller Schnittstellenstandard verabschiedet, welcher über Verschlüsselung einen sicheren Tunnel für Datenverbindungen in unsicheren Netzen ausbildet. Für die sicherheitsrelevanten Informationen als solche, stellen diese Schnittstellenstandards HBCI oder OFX (Open Financial Exchange) lediglich ein der Online-Verbindung zugrunde liegendes Übertragungsprotokoll dar. Durch die in diesem Standard festgelegte Multibankfähigkeit können die Kunden mit verschiedenen Finanzdienstleistern über dieselbe Anwendung sicher kommunizieren. Nachteilig bei derartigen Verfahren ist, daß das Programmodul des Terminals speziell an die ausführbare Finanztransaktion und die kontoführende Bank angepaßt sein muß.

Die Aufgabe der Erfindung besteht in der Realisierung eines Systems, mit dem verschiedene Finanztransaktionen von beliebigen, über ein Netzwerk erreichbaren Terminals aus, zu verschiedenen Finanzdienstleistern sicher ausgeführt werden können. Dadurch sollen funktionell vergleichbare Finanzdienstleistungen verschiedener Finanzdienstleister in ein funktionell übergreifendes System integrierbar sein.

Ein wesentlicher Aspekt der Aufgabe ist die Beibehaltung der bestehenden spezifischen EDVA der Finanzdienstleister sowie deren spezifischer Ausbildung der Transak- tionsformularitäten. Ein weiterer wesentlicher Aspekt besteht in der Bereitstellung einer maximalen Inter- operabilität zwischen den einzelnen Finanzdienstleistungen, um bei geringem Aufwand verschiedene Kombinationen dieser und eine vernetzte Abwicklung zu ermöglichen.

Die Aufgabe wird durch die im Patentanspruch 1 aufgeführten Merkmale gelöst. Bevorzugte Weiterbildungen ergeben sich aus den Unteransprüchen.

Das Wesen der Erfindung besteht in der Realisierung einer Finanz-Transaktions-Schnittstelle, welche auf einer Client- Server-Verbindung zwischen dem Endkundenrechner und einem zentralen Basissystem, welches über eine Vielzahl spezieller Schnittstellen mit den spezifischen EDVA'n der Finanzdienstleister verbunden ist, beruht, wobei über eine zentrale Elementbasis und ein Formularerstellungsmodul jeweils für einen angebotenen Geschäftsvorfall und einen anbietenden Finanzdienstleiter ein spezielles Anwendungs- modul mit den spezifischen Transaktionsformularitäten des spezifischen Finanzdienstleisters einfach erstellbar ist und dieses jedem Kunden online zur Verfügung steht. Die erzeugten Anwendungsmodule gestatten eine für Finanz- transaktionen sichere Online-Verbindung und werden aus- schließlich mit Basiselementen der zentralen Elementbasis in einer logischen Zwischenschicht beschrieben, die sich logisch zwischen der Verbindungsschicht und den spezi-

fischen Datenelementen einzelner Finanzdienstleister befindet.

Es ist günstig, das Formularerstellungsmodul graphisch un- terstützt auszuführen, damit direkt auf bereits daten- technisch erstellte Formulare für Finanztransaktionen zugegriffen werden kann.

Die Vorteile der Erfindung liegen insbesondere in der Schaffung einer Integrationsplattform für Finanz- dienstleistungen verschiedener Finanzdienstleister in Form einer virtuellen Bankfiliale zur vollautomatischen Ab- wicklung von Geschäftsprozessen. Durch die Integration heterogener Systemumgebungen kann mit Geschäftsvorfällen dritter Finanzdienstleister gemakelt werden und eine Vertriebsstreuung wird unterstützt. Durch die Bündelung von Vertriebskanälen wird zudem deren Bearbeitung unterstützt.

Dies ermöglicht eine vollelektronische Abwicklung zu Verbundpartnern sowie eine Rationalisierung im Back-Office, insbesondere eine Bereitstellung eines Allfinanzangebotes ohne eigenes Back-Office. Dadurch können die Vorteile von als Generalisten tätigen Großbanken und die der als Spezialisten tätigen Kleinanbieter zusammengefaßt werden.

Zusätzlich ist eine optimale Kundenkommunikation auf allen elektronischen Medien und mit allen Protokollen realisierbar und alle Produkte werden homogen beim Kunden präsentiert. Eine individuelle Kundenansprache kann ebenso integriert werden. Eine rationelle Datenbeschaffung aus bestehenden Bankanwendungen heraus wird durch das Formularerstellungsmodul unterstützt. Bei einer Umstellung

seitens des Finanzdienstleisters erfolgt eine einfache Um- stellung auf andere Datenquellen.

Die Erfindung wird als Ausführungsbeispiel an Hand von Fig. 1 als Finanz-Transaktions-Schnittstelle Fig. 2 als Implementationsverfahren in bestehende Finanztransaktionen näher erläutert.

Die Finanz-Transaktions-Schnittstelle besteht nach Fig. 1 aus einer Client-Server-Lösung, bei welcher auf einem als Client dienenden Endkundenrechner 1, der beispielsweise einen internetfähigen PC, einen Selbstbedienungskiosk oder ein Mitarbeiterterminal darstellt, ein Anwendungsmodul 2 für Finanzdienstleistungen in einem geeigneten Betriebs- system ausgeführt wird, vorzugsweise als JAVA-Applet, Plug- In oder auch als Offline-Applikation, welches von einem als Server dienenden Basissystem 3 kontrolliert und weiter- geleitet wird. Vorzugsweise wird ein hinreichend sicheres Verschlüsselungsverfahren, bspw. 128 Bit SSL, zur Daten- übertragung unterstützt und beim Übergang zum offenen Netz 4 ist ein Firewall vorgeschaltet. Die für Finanz- transaktionen notwendigen Sicherheitsstandards, z. B. SET ; HBCI ; OFX werden unterstützt. Die Endkundenautorisierung erfolgt bspw. über PIN/TAN ; RSA-Software ; RSA-Chip ; Token.

Das Basissystem 3 selbst ist vorteilhaft funktionell modular aufgebaut aus den Modulen : Security-Server 5-zur Transaktionssicherheit der Verbindungsschicht bei offenen Netzen 4, bspw. SET ; HBCI, OFX,...

Datenmanager 6-für kundenspezifische Daten bei Finanztransaktionen, bspw. PIN/TAN, Chip, Token..., Transformationsmodul 7-zur Transformation der Elemente 8 /Basiselemente 9 für eine einheitliche Darstellung über eine einheitliche Zwischenschicht, wobei die Basiselemente 9 vorteilhaft als Generic Business Interface ausgebildet sind, Protokollwandler 10-spezifische Protokollanpassung der Verbindungsschicht bezüglich einer speziellen Bank-EDVA 11, bspw. TCP/IP, SNA Lu6.2,...

Das Anwendungsmodul 2 greift auf eine für alle Finanz- dienstleister und alle Geschäftsvorfälle einheitliche Zentrale Elementbasis 12 zurück, welche alle Geschäfts-und finanzdienstleisterspezifischen Elemente 8 über die Zwischenschicht funktionell identischen Basiselementen 9 zuordnet, wobei einzelne Geschäftsvorfälle eindeutig über eine Kennung 13 bezeichnet sind. In den Schichtaufbau : [Verbindungsschicht-Elemente 8-Anwendungsapplikation] ordnet sich diese auf den Basiselementen 9 aufbauende Zwischenschicht zwischen der Verbindungsschicht und den Elementen 8 ein. Das Anwendungsmodul 2 arbeitet bezüglich einer Finanztransaktion ausschließlich mit diesen Basiselementen 9 und deshalb geschäfts-und finanz- dienstleisterübergreifend in der Zwischenschicht. Die geschäfts-und finanzdienstleisterspezifische Ausbildung, insbesondere die Transaktionsformularitäten sowie deren graphische Darstellung werden zuvor einmalig durch ein zentral verfügbares, vorzugsweise graphisches, Formular- erstellungsmodul 14 generiert, indem von bestehenden spezifischen Anwendungen ausgehend in einem modularen Prozeß die spezifische Verbindungsschicht neutralisiert und

anschließend die Struktur der geschäfts-und finanz- dienstleisterspezifischen Elemente 8 der spezifischen Anwendungen durch eine adäquate Struktur der Basiselemente 9 als Generic Business Interface (GBI) über Pakethändler nachgebildet wird, z. B : eine eindeutig definierte Kennung 13 als Bezeichner für den Geschäftsvorfall"Money Transfer", wobei dieser Bezeichner mit der fachlichen Nutzungsanweisung und Informationen über den zu verwendenden Kontext abgelegt ist. Jedes GBI ist aus diesem über alle Kunden und Systeme einheitlichen Bezeichnung des Geschäftsvorfalls aufgebaut.

Nach der Benennung des Geschäftsvorfalls besteht jedes Interface aus einer Anfrage (Request) und beliebigen Antworten (Replay). Ein Request oder Replay besteht aus einer Menge von eindeutig bezeichneten Datenelementen, die in jedem Anwendungskontext beliebige Länge, beliebigen Typ und Inhalt haben können. Die fachlichen, einheitlichen Bezeichner sind ebenfalls in einer Datenbank (Depository) hinterlegt und beschrieben.

Es ist vorteilhaft vorstellbar, daß die Basiselemente 9 in Form eines Generic Business Interface bezüglich ihres Inhalts, welcher deren Zustand beschreibt, und optional der darauf aufbauenden Funktionen als ein weltweit ver- bindlicher Standard verwendet werden. Ebenso ist es günstig, alle Zustände und die jeweils darauf aufbauenden Funktionen in der Art eines math. Graphen rechentechnisch zu verwalten und optional darzustellen, bspw. über eine Statemachine zu kombinieren.

Eine über das Anwendungsmodul 2 im Endkundenrechner 1 über Basiselemente 9 beschriebene Finanztransaktion gelangt über den Security-Server 5, welcher eine für Finanztransaktionen sichere Verbindung über offene Netze aufbaut in das Transformationsmodul 7 des Datenmanagers 6. Dieser greift auf die vollständige zentrale Elementbasis 12 als Depository und den jeweiligen Abbildungen der einzelnen geschäfts-und finanzdienstleisterspezifischen Elemente 8 zu und transformiert die Basiselemente 9 zurück in die jeweilige Darstellungen des Finanzdienstleisters. Im Datenmanager 6 selbst findet vorzugsweise in einem Datenspeicher die für die 24h-Fähigkeit notwendige Zwischenspeicherung von personalisierten Daten statt.

Gesteuert über den Datenmanager 6 erfolgt über eine Zwischenschaltung des jeweiligen Protokollwandlers 10 die Verbindung mit der jeweiligen Bank-EDVA 11.

Nach Fig. 2 erfolgt zur Implementation der Finanz-Trans- aktions-Schnittstelle in bestehende Finanztransaktionen in einen ersten Schritt die Generierung der einzelnen Anwendungsmodule 2 als eine Abbildung einzelner geschäfts-und finanzdienstleister- spezifischer Ausbildungen des nachgebildeten Geschäfts- vorfalls, insbesondere von Transaktionsformularitäten sowie deren graphischer Darstellung, durch ein zentral verfügbares-vorzugsweise graphisches-Formular- erstellungsmodul 14, indem von bestehenden spezifischen Anwendungen ausgehend, in einem modularen Prozeß die spezifische Verbindungsschicht neutralisiert und an- schließend die Struktur der geschäfts-und finanz- dienstleisterspezifischen Elemente 8 der spezifischen

Anwendungen durch eine adäquate Struktur einzelner Basiselemente 9 der zentralen Elementbasis 12 nachgebildet wird. In Verbindung mit dem zugeordneten Protokollwandler 10 ist durch die über Einzelne Basiselemente 9 einer vollständigen zentralen Elementbasis 12 beschriebene Abbildung stets eine eindeutige Rücktransformation gegeben.

Durch den modularen Prozeß im Formularerstellungsmodul 14 wird eine rationelle Daten-bzw. Formularbeschaffung aus bestehenden Datenquellen unterstützt, bspw. aus Bildschirmseiten (3270, BTX,...), Datenbanken (DB/2, SQL, ...), von Hosts (MVS, BS2000,...) oder bereits bestehenden Bankanwendungen (KORDOBA, MBS-OPEN,...). Die eindeutige Zuordnung der Kennung 13 für jeden nachgebildeten Geschäftsvorfall gestattet eine parallele Entwicklung der einzelnen Anwendungsmodule 2.

In einem zweiten Schritt erfolgt der Test der einzelnen Anwendungsmodule 2 parallel zu den bestehenden Finanztransaktionen des Finanz- dienstleisters, indem über ein Paar Testrechner mit Transformationsmodule 7, Protokollwandler 10 und Zugriff auf die zentrale Elementbasis 12 eine begleitende Abbildung auf die Basiselemente 9 sowie deren Rücktransformation vorgenommen und deren Identität verglichen wird.

In einem dritten Schritt wird die erfolgreich getestete Abbildung auf die Basis- Elemente 9 sowie deren Rücktransformation direkt in die Finanz-Transaktions-Schnittstelle eingebunden, indem diese in die zentrale Elementbasis 12 eingebunden wird. Dadurch ist deren Aktivierung im laufenden Bankgeschäft des Finanzdienstleisters jederzeit möglich.

Über dieses Verfahren ergibt sich eine kurze Implemen- tierungsdauer bei geringem Resourcenaufwand, eine hohe Qualität des nachgebildeten Geschäftsvorfalls und eine einfache zentrale Updatefähigkeit.

Zur Selbstkonfiguration der Finanz-Transaktions-Schnitt- stelle, welche eine weitere vorteilhafte Ausbildung darstellt, muß der Finanzdienstleister eine einmalige Initialisierung vornehmen, die in der Einbindung des Protokollwandlers in seine Bank-EDVA besteht, wodurch dessen Spezifik neutralisiert wird. Über die Definition seiner komplexen Dienste aus Basisdiensten, welche vorteilhaft weltweit über einen Standard, bspw."Generic Business Interface"festgelegt sind, werden die speziellen Finanzdienstleistungen beschrieben und beim Finanz- dienstleister gespeichert. Dadurch wird seitens des Basis- systems eine vollständige Mengenanfrage, welche alle Basis- dienste umfaßt, bezüglich einer Finanzdienstleister EDVA ermöglicht, deren Antwort, welche insbesondere die Verfüg- barkeit und die Anforderungen enthält, anschließend vom Basissystem ausgewertet wird und aus den verfügbaren Basisdiensten eine Verwendungsmenge des speziellen Finanz- dienstleisters in Echtzeit zusammenstellt. Eine einzelne, in der Mengenabfrage enthaltene, derartige Abfrage der Form :"Was brauchst du für diesen Dienst"und die zugeordnete Antwort könnte bspw. konkret wie folgt generiert sein : MeEntryListApplet-ServerPID="PIDDIALOGINFO" : [MMPACKAGEINFO, MD_INT {"PID-PIN LOGIN"}]

Was brauchst du für ## ? Dialog Info ? MeEntryListServerAppletPID="PID-DIALOG-INFO" : [MMPACKAGEINFO, MDENTRYLIST :] User ID, Typ String [MMFIELDDESKRIBTION ; MDPOINT{'MMUSERID';'MDSTRING'}] [MMFIELDDESKRIBTION ; MD_POINT {MM PIN'; MD_STRING'}] PIN Typ String, unbegrenzte Länge Die Mengenabfrage kann auch strukturiert erfolgen in der Form : "Was für Basisdienste unterstützt Du ?" "Was brauchst Du für ### speziell ?" Anschließend kann das Anwendungsmodul generiert werden, wozu das finanzdienstleisterspezifische graphische Layout, das üblicherweise in einem ausführbaren Format vorliegt, im Formulareditor mit dem Inhalt einzelner Geschäftsvorfälle verknüpft wird. Mittels einer vorteilhaft weltweit stan- dardisierten Definition von Basisdiensten kann über eine Verknüpfung entsprechend ihrer Kennung zugeordneter und automatisch generierter Pakethändler diese Generierung des Anwendungsmoduls, welches das Frontend zum Kunden darstellt, automatisch erfolgen. Es steht fortan für konkrete Finanztransaktionen zur Verfügung.

Verwendete Bezugszeichen 1 Endkundenrechner 2 Anwendungsmodul 3 Basissystem 4 Netz 5 Security-Server 6 Datenmanager 7 Transformationsmodul 8 geschäfts-und finanzdienstleisterspezifische Elemente 9 Basiselemente, auch als Generic Business Interface (GBI) 10 Protokollwandler 11 Bank-EDVA 12 zentrale Elementbasis 13 Kennung 14 Formularerstellungsmodul