DE19922836C2 - Verfahren zur Funktion, Implementation sowie Selbstkonfiguration einer Finanz-Transaktions-Schnittstelle - Google Patents

Description

Die Erfindung bezeichnet ein Verfahren zur Funktion, Imple­ mentation sowie Selbstkonfiguration einer Finanz-Trans­ aktions-Schnittstelle, welche als Client-Server-Lösung für netzwerkfähige Finanztransaktionen zwischen einem Kunden­ rechner und den diese Finanztransaktion ausführenden EDVA'n der Finanzdienstleister angeordnet ist, insbesondere für Anwendungen über das Internet zum Makeln von Geschäftsvor­ fällen.

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 direk­ te Fokussierung auf den Endkunden geprägt. Auf der Kunden­ seite ü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 Be­ darfslü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 in­ nerhalb der Klasse G07F selbstkassierende und ähnliche Ge­ räte bekannt, wobei speziell unter G07F 19/00 vollständige Banksysteme und Bank-Transaktions-Geräte klassifiziert sind. Die Druckschrift DE 25 59 136 A1 offenbart eine Vor­ richtung für ein vollautomatisches Banksystem zum Abwickeln 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 eines von mehreren ver­ schiedenen Bankgeschäften ausgewählt. Die Druckschrift DE 43 33 388 A1 offenbart die Möglichkeit, mit Hilfe einer als Multifunktionskarte ausgeführten Chipkarte verschiedene Fi­ nanztransaktionen der kontoführenden Bank sicher zu täti­ gen. Dazu führt der Kunde diese Multifunktionskarte in ein mit der EDVA der Bank verbundenes Terminal ein. Dabei wer­ den bezüglich der getätigten Transaktion sichere Transakti­ onsdaten über Verschlüsselungsroutinen berechnet und von der Gegenseite überprüft. Aus historischen Gründen existie­ ren eine Vielzahl verschiedener anbieterabhängiger Standards für die Ansprache von Chipkarten. Die Druckschrift WO 97/05582 stellt deshalb ein System vor, bei welchem ein einheitliches systemunabhängiges Kundenterminal über eine, Online-Verbindung mit einem Basisterminal verbunden ist, welches eine Vielzahl derartiger spezieller Chipkartenter­ minalmodule beinhaltet. Nachteilig bei derartigen Verfahren ist, daß ein spezielles, im Verantwortungsbereich der Bank liegendes Terminal als Fernbankschalter verwendet werden muß, sowie das Progammodul des Terminals speziell an die über die Karte ausführbare Finanztransaktion und die konto­ führende Bank angepaßt sein muß.

Es ist aus dem Stand der Technik bekannt, verschiedene Dienstleistungen mittels eines Heimrechners online auszu­ führen. Die nur virtuell erreichbare Gegenseite bildet dazu eine virtuelle Filiale aus, bspw. als virtuelles 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 erfol­ gen. 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 Ver­ schlüsselung einen sicheren Tunnel für Datenverbindungen in unsicheren Netzen ausbildet. Für die sicherheitsrelevanten Informationen als solche, stellen diese Schnittstellenstan­ dards HBCI oder OFX (Open Financial Exchange) lediglich ein der Online-Verbindung zugrunde liegendes Übertragungsproto­ koll dar. Durch die in diesem Standard festgelegte Multi­ bankfähigkeit können die Kunden mit verschiedenen Finanz­ dienstleistern über dieselbe Anwendung sicher kommunizie­ ren. Nachteilig bei derartigen Verfahren ist, daß das Pro­ grammodul des Terminals speziell an die ausführbare Finanz­ transaktion und die kontoführende Bank angepaßt sein muß.

Die Aufgabe der Erfindung besteht in der Realisierung eines Systems, mit dem verschiedene Finanztransaktionen von be­ liebigen, über ein Netzwerk erreichbaren Terminals aus, zu verschiedenen Finanzdienstleistern sicher ausgeführt werden können. Dadurch sollen funktionell vergleichbare Finanz­ dienstleistungen 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 be­ steht 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.

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 speziel­ ler Schnittstellen mit den spezifischen EDVA'n der Finanz­ dienstleister verbunden ist, beruht, wobei über eine zen­ trale Elementbasis und ein Formularerstellungsmodul jeweils für einen angebotenen Geschäftsvorfall und einen anbieten­ den Finanzdienstleister ein spezielles Anwendungsmodul mit den spezifischen Transaktionsformularitäten des spezifi­ schen Finanzdienstleisters einfach erstellbar ist und die­ ses jedem Kunden online zur Verfügung steht. Die erzeugten Anwendungsmodule gestatten eine für Finanztransaktionen si­ chere Online-Verbindung und werden ausschließlich mit Basi­ selementen der zentralen Elementbasis in einer logischen Zwischenschicht beschrieben, die sich logisch zwischen der Verbindungsschicht und den spezifischen Datenelementen ein­ zelner 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 zuge­ griffen 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 he­ terogener Systemumgebungen kann mit Geschäftsvorfällen dritter Finanzdienstleister gemakelt werden und eine Ver­ triebsstreuung 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 Spezia­ listen tätigen Kleinanbieter zusammengefaßt werden. Zusätz­ lich ist eine optimale Kundenkommunikation auf allen elek­ tronischen 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 Formularerstellungs­ modul unterstützt. Bei einer Umstellung seitens des Finanz­ dienstleisters erfolgt eine einfache Umstellung 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 ei­ nen 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 modu­ lar aufgebaut aus den Modulen:
Security-Server 5 - zur Transaktionssicherheit der Verbin­ dungsschicht bei offenen Netzen 4, bspw. SET; HBCI, OFX, . . .
Datenmanager 6 - für kundenspezifische Daten bei Finanz­ transaktionen, 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 Zen­ trale Elementbasis 12 zurück, welche alle Geschäfts- und finanzdienstleisterspezifischen Elemente 8 über die Zwi­ schenschicht funktionell identischen Basiselementen 9 zu­ ordnet, wobei einzelne Geschäftsvorfälle eindeutig über ei­ ne Kennung 13 bezeichnet sind. In den Schichtaufbau:
[Verbindungsschicht - Elemente 8 - Anwendungsapplikation]
ordnet sich diese auf den Basiselementen 9 aufbauende Zwi­ schenschicht zwischen der Verbindungsschicht und den Ele­ menten 8 ein. Das Anwendungsmodul 2 arbeitet bezüglich ei­ ner Finanztransaktion ausschließlich mit diesen Basisele­ menten 9 und deshalb geschäfts- und finanz­ dienstleisterübergreifend in der Zwischenschicht. Die ge­ schäfts- und finanzdienstleisterspezifische Ausbildung, insbesondere die Transaktionsformularitäten sowie deren graphische Darstellung werden zuvor einmalig durch ein zen­ tral 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 An­ wendungen 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 Be­ zeichner mit der fachlichen Nutzungsanweisung und Informa­ tionen über den zu verwendenden Kontext abgelegt ist. Jedes GBI ist aus diesem über alle Kunden und Systeme einheitli­ chen 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 eindeu­ tig bezeichneten Datenelementen, die in jedem Anwendungs­ kontext beliebige Länge, beliebigen Typ und Inhalt haben können. Die fachlichen, einheitlichen Bezeichner sind eben­ falls in einer Datenbank (Depository) hinterlegt und be­ schrieben.

Es ist vorteilhaft vorstellbar, daß die Basiselemente 9 in Form eines Generic Business Interface bezüglich ihres In­ halts, welcher deren Zustand beschreibt, und optional der darauf aufbauenden Funktionen als ein weltweit ver­ bindlicher Standard verwendet werden. Ebenso ist es gün­ stig, 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 Trans­ formationsmodul 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 transfor­ miert die Basiselemente 9 zurück in die jeweilige Darstel­ lungen des Finanzdienstleisters. Im Datenmanager 6 selbst findet vorzugsweise in einem Datenspeicher die für die 24 h- Fähigkeit notwendige Zwischenspeicherung von personalisier­ ten Daten statt. Gesteuert über den Datenmanager 6 erfolgt über eine Zwischenschaltung des jeweiligen Protokollwand­ lers 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ügba­ res - vorzugsweise graphisches - Formularerstellungsmodul 14, indem von bestehenden spezifischen Anwendungen ausge­ hend, in einem modularen Prozeß die spezifische Verbin­ dungsschicht neutralisiert und anschließend die Struktur der geschäfts- und finanzdienstleisterspezifischen Elemente 8 der spezifischen Anwendungen durch eine adäquate Struktur einzelner Basiselemente 9 der zentralen Elementbasis 12 nachgebildet wird. In Verbindung mit dem zugeordneten Pro­ tokollwandler 10 ist durch die über Einzelne Basiselemente 9 einer vollständigen zentralen Elementbasis 12 beschriebe­ ne Abbildung stets eine eindeutige Rücktransformation gege­ ben. 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 Bankanwen­ dungen (KORDOBA, MBS-OPEN, . . .). Die eindeutige Zuordnung der Kennung 13 für jeden nachgebildeten Geschäftsvorfall gestattet eine parallele Entwicklung der einzelnen Anwen­ dungsmodule 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 Trans­ formationsmodule 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 Fi­ nanz-Transaktions-Schnittstelle eingebunden, indem diese in die zentrale Elementbasis 12 eingebunden wird. Dadurch ist deren Aktivierung im laufenden Bankgeschäft des Finanz­ dienstleisters jederzeit möglich.

Über dieses Verfahren ergibt sich eine kurze Implemen­ tierungsdauer bei geringem Ressourcenaufwand, eine hohe Qualität des nachgebildeten Geschäftsvorfalls und eine ein­ fache zentrale Updatefähigkeit.

Zur Selbstkonfiguration der Finanz-Transaktions-Schnitt­ stelle muß der Finanzdienstleister eine einmalige Initia­ lisierung vornehmen, die in der Einbindung des Protokoll­ wandlers in seine Bank-EDVA besteht, wodurch dessen Spezi­ fik neutralisiert wird. Über die Definition seiner komple­ xen Dienste aus Basisdiensten, welche vorteilhaft weltweit über einen Standard, bspw. "Generic Business Interface" festgelegt sind, werden die speziellen Finanzdienstleistun­ gen beschrieben und beim Finanzdienstleister gespeichert. Dadurch wird seitens des Basissystems eine vollständige Mengenanfrage, welche alle Basisdienste umfaßt, bezüglich einer Finanzdienstleister EDVA ermöglicht, deren Antwort, welche insbesondere die Verfügbarkeit und die Anforderungen enthält, anschließend vom Basissystem ausgewertet wird und aus den verfügbaren Basisdiensten eine Verwendungsmenge des speziellen Finanzdienstleisters 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 ge­ neriert sein:
MeEntryListApplet→ServerPID = "PID_DIALOG_INFO":
{
[MM_PACKAGE_INFO, MD_TNT{"PID_PIN_LOGIN"}]
}
Was brauchst du für ##?
Dialog Info?
MeEntryListServer→AppletPID = "PID DIALOG INFO":
{
[MM_PACKAGE_INFO, MD_ENTRY_LIST:]
{
User ID, Typ String
[MM_FIELD_DESKRIBTION;
MD_POINT{'MM_USER_ID'; 'MD_STRING'}]
[MM_FIELD_DESKRIBTION;
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, wo­ zu 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 au­ tomatisch generierter Pakethändler diese Generierung des Anwendungsmoduls, welches das Frontend zum Kunden dar­ stellt, 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

Claims (1)

1. Verfahren zur Funktion, Implementation sowie Selbstkon­ figuration einer Finanz-Transaktions-Schnittstelle, die aus einer Client-Server-Lösung besteht, wobei das als Server dienende Basissystem (3) einen Security-Server (5), einen Datenmanager (6) für kundenspezifische Daten, ein Transfor­ mationsmodul (7) und einen Protokollwandler (10) aufweist und die Anwendungen für Finanzdienstleistungen, die auf ei­ nem als Client dienenden Endkundenrechner (1) ausgeführt wird, auf eine Basis/Datenbank zugreift, die vereinheit­ lichte geschäfts- und finanzdienstleisterspezifische Ele­ mente (8) aufweist, dadurch gekennzeichnet,
dass zur Funktion
in einem ersten Übertragungsschritt,
eine über ein Anwendungsmodul (2) über Basiselemente (9) beschriebene Finanztransaktion über den Security-Server (5), welcher eine für Finanztransaktionen sichere Verbin­ dung über offene Netze (4) aufbaut, in das Transformations­ modul (7) des Datenmanagers (6) gelangt;
in einem zweiten Übertragungsschritt,
dieser auf eine vollständige zentrale Elementbasis (12) und den jeweiligen Abbildungen der einzelnen geschäfts- und fi­ nanzdienstleisterspezifischen Elemente (8) zugreift und die Basiselemente (9) der logischen Zwischenschicht zurück in die jeweilige Darstellung des Finanzdienstleisters trans­ formiert,
in einem dritten Übertragungsschritt,
im Datenmanager (6) selbst, in einem Datenspeicher, die für die 24h-Fähigkeit notwendige Zwischenspeicherung von perso­ nalisierten Daten stattfindet und über eine Zwischenschal­ tung des jeweiligen Protokollwandlers (10) die Verbindung mit der jeweiligen Bank-EDVA (11) erfolgt;
dass eine Implementation in bestehende Finanztransaktionen beteiligter heterogener Finanzdienstleister,
in einem ersten Schritt,
die Generierung der einzelnen Anwendungsmodule (2) durch ein zentral verfügbares Formularerstellungsmodul (14) er­ folgt, indem von bestehenden spezifischen Anwendungen aus­ gehend in einem modularen Prozeß die spezifische Verbin­ dungsschicht neutralisiert und anschließend die Struktur der geschäfts- und finanzdienstleisterspezifischen Elemente (8) der spezifischen Anwendungen durch eine adäquate Struk­ tur einzelner Basiselemente (9) der zentralen Elementbasis (12) nachgebildet wird;
in einem zweiten Schritt,
der Test der einzelnen Anwendungsmodule (2) parallel zu den bestehenden Finanztransaktionen des Finanzdienstleisters erfolgt, indem über ein Paar Testrechner mit Transformati­ onsmodulen (7), Protokollwandlern (10) und Zugriff auf die zentrale Elementbasis (12) eine begleitende Abbildung auf die Basiselemente (9) sowie deren Rücktransformation vorge­ nommen und deren Identität verglichen wird;
in einem dritten Schritt,
die erfolgreich getestete Abbildung auf die Basiselemente (9) in die zentrale Elementbasis (12) der Finanz- Transaktions-Schnittstelle eingebunden wird; und
dass in einer Selbstkonfiguration,
in einem ersten Schritt,
die einmalige Initialisierung von Transformationsmodulen (7) und Protokollwandlern (10) seitens der jeweiligen Bank-EDVA (11) des Finanzdienstleisters erfolgt und optional aus Ba­ sisdiensten zusammengesetzte finanzdienstleisterspezifische Komplexdienste definiert werden, wodurch die Spezifik der Bank-EDVA (11) neutralisiert wird;
in einem zweiten Schritt,
seitens des Basissystems (3) eine vollständige Mengenabfra­ ge erfolgt, welche alle Basisdienste umfaßt, die entspre­ chend der finanzdienstleisterspezifischen Bank-EDVA (11) beantwortet und seitens des Basissystems (3) in Echtzeit ausgewertet wird, wodurch eine Verwendungsmenge von verfüg­ baren Basisdiensten dynamisch festgestellt ist, die von der finanzdienstleisterspezifischen Bank-EDVA (11) unterstützt wird;
in einem dritten Schritt,
die Generierung der einzelnen Anwendungsmodule (2) mittels eines zentral verfügbaren Formularerstellungsmoduls (14) erfolgt, indem innerhalb der Verwendungsmenge verfügbarer Basisdienste die Struktur der geschäfts- und finanzdienst­ leisterspezifischen Elemente (8) der spezifischen Anwendun­ gen durch eine adäquate Struktur einzelner Basiselemente (9) der zentralen Elementbasis (12) über automatisch generier­ te, den einzelnen Geschäftsvorfällen zugeordnete, Pa­ kethändler nachgebildet wird; und
in einem letzten Schritt,
die Bereitstellung des Anwendungsmoduls für die eigentliche Abwicklung einer oder mehrerer Finanztransaktionen, basie­ rend auf der Verwendungsmenge von unterstützten Basisdien­ sten, erfolgt.