Die "Passive EDIFACT-Fähigkeit" in der Praxis Stand - Nutzen - Zukunft - Lösungen Marcus Graf & Klaus Wolf

Transkript

1 Die "Passive EDIFACT-Fähigkeit" in der Praxis Stand - Nutzen - Zukunft - Lösungen Marcus Graf & Klaus Wolf EDIFACT ein UN-Standard der alle Geschäftsvorgänge ermöglicht ist erfolgreich auf dem Vormarsch. In den Bereichen Produktion, Handel und Transport ist EDIFACT bereits auf breiter Basis im Einsatz. Ob es die Automobilindustrie ist, der Handel, der ohnehin mit knappen Margen arbeitet, oder die Bankindustrie, die sich in einen grundlegenden Wandel begibt alle bedienen sich des universellen und weltweit einheitlichen EDIFACT-Formates. Durch den Binnenmarkt und den zunehmenden Einsatz von ecommerce (sicherer elektronischer Geschäftsdatenaustausch z.b. via Internet etc.) wird diese Entwicklung noch beschleunigt. Im Bereich Buchhaltung und Zahlungverkehr klafft in der "electronic loop" noch eine der größeren Lücken. Die Betriebe könnten zwar durch den Einsatz von Formatkonvertern die Zahlungsvorgänge aus der Buchhaltungssoftware als EDIFACT-Dateien exportieren, jedoch sind viele Banken z.zt. noch nicht in der Lage, EDIFACT-Daten anzunehmen und vollumfänglich zu verarbeiten. Besonders wirkt sich das im "elektronischen Auszug" FINSTA aus. Dieser ist Grundlage für eine automatische Verbuchung (Buchungsvorlage) mit umfangreichen Rechnungsnummern in einem Zahlungsvorgang. Am Beispiel einer größeren Mittelstandsbank möchten wir die Inhouse-Anforderungen an die DV- Systeme darstellen. Als wichtiger Part ist dabei auch der Firmenkunde zu sehen, der FINANCIAL EDIFACT einliefert und sicher und effizient transportiert wissen möchte. Ausgangspunkt Die Banken sind z.zt. durch das Jahr 2000, die EURO-Umstellung und andere marktbedingte Umstellungen bereits voll ausgelastet. Trotzdem haben sie sich in der Neufassung des Clearingabkommens gegenseitig verpflichtet, zum die "Passive EDIFACT-Fähigkeit" zu realisieren. Warum diese Selbstverpflichtung der deutschen Banken? Bisher tauschen die Banken via LZB oder bilateral die nationalen oder S.W.I.F.T.-Formate aus. Problem hierbei sind die begrenzten Verwendungszwecke und die inzwischen über 64 verschiedenen Ausprägungen allein des MT940- Kontoauszugsformates. Zudem nutzt jede Bank individuell angepasste Zahlungsverkehrssysteme die einen Transport dieser möglicherweise sehr umfangreichen Verwendungszwecke derzeit nicht vorsehen. Der Wunsch der Firmenkundschaft ist klar: Direkt in/aus der Buchhaltung mittels EDIFACT-Format zum Partner. Vorgänge, die vorher verschiedene Referenzen benötigten, sollen möglichst auf einen Vorgang vereinfacht werden. Ziel ist die Reduktion von Medienbrüchen. by EDIGroup, nicht-gewerblicher Nachdruck gegen Belegexemplar gestattet. - 1/12

2 Mit dem Einsatz von FINPAY, dem weltweit festgelegten EDIFACT-Format zur Interbankverrechnung, ist der "Container" geschaffen. Vorteil bei der vollumfänglichen Weiterleitung von der Einlieferung bis zum Endkunden sind exakte Debitoren/Kreditorendaten. Diese sind insbesondere beim künftigen Einsatz von ecommerce wichtig für den CashFlow und die Aufwandsreduzierung in der Finanzbuchhaltung. Geprägt durch den Binnenmarkt, die neue Europäische Zentralbank in FFM und die Verrechnungssysteme TARGET, EAF II, ELS, EZÜ wird durch den Einsatz von EDIFACT eine neue Dimension entstehen. Dieser Anforderungen müssen sich die europaweiten Abrechnungssysteme stellen. Auch internationale Formate wie S.W.I.F.T. etc. werden neben den bisherigen nationalen Formaten hiervon betroffen sein. Dies ist von allen Beteiligten rechtzeitig erkannt worden, doch die Umsetzung fällt vielerorts schwer. Zukünftige Entwicklungen Mitte 1999 wird EU-seitig ein verbindliches Dekret herauskommen, das den Binnenmarktbanken vorschreibt, Zahlungen vom Auftraggeber zum Begünstigten in maximal sechs Tagen durchzuführen bzw. auf den Konten gutzuschreiben. Bis zu Euro pro Vorgang Schadensersatzforderungen an die Banken sollen bei nachgewiesenem Schaden fällig werden. Einmalig in der deutschen Bankgeschichte! Neben den Verschärfungen in der Wertstellung (Floatgewinne) ergeben sich daraus große logistische Probleme in den Leitwegen und deren Steuerung. Die Z1-Meldung (derzeit notwendig bei clean payments, Zahlungsausgängen aus Deutschland über DM) wird dann voraussichtlich auf Euro erhöht. Und statt der deutschen Bankleitzahl oder SWIFT-Adresse werden wir uns an den BIC (Banking Identification Code) gewöhnen müssen. Die Neufassung des Clearingabkommens Das Clearingabkommen regelt den Datenaustausch im Massenzahlungsverkehr zwischen den Kreditinstituten. Bisherige Praxis Zwischen großen Filialbanken, Kopfstellen der Sparkassen u. Genossenschaftsbanken sowie Privatbanken erfolgt das zwischenbetriebliche Clearing durch Trennung von Nachricht und Verrechnung: Bilateraler Austausch der Zahlungsverkehrsdateien (Nachricht) per DFÜ oder Datenträger (Magnetband,-kassette) Deckungszahlung (Verrechnung) über die elektronischen Abrechnungsverfahren der Bundesbank (EAF/ELS) Kleinere Institute nehmen am zwischenbetrieblichen Clearing über die Bundesbank teil: Keine Trennung von Nachricht und Verrechnung; by EDIGroup, nicht-gewerblicher Nachdruck gegen Belegexemplar gestattet. - 2/12

3 Einlieferung der Zahlungsverkehrsdateien an die Bundesbank per Magnetband, zukünftig elektronisch (E-DTA) Neuregelung gemäß Clearingabkommen (Siehe EDIFACT-Clearing-Leitfaden) Ab ist neben dem DTA-Format auch das EDIFACT-Format, Nachrichtenart FINPAY, für das zwischenbetriebliche Clearing zugelassen. Dabei besteht insbesondere die Verpflichtung, alle im Datensatz enthaltenen Angaben zum Zahlungsvorgang "vollumfänglich" an den Empfänger weiterzuleiten. Der Austausch von EDIFACT-Nachrichten erfolgt ausschließlich über DFÜ. Einschränkungen: Das zwischenbetriebliche Clearing (E-DTA-Verfahren) über die Bundesbank wird erst ab Mitte 2000 im EDIFACT-Format möglich sein. Das EDIFACT-Format FINPAY soll zunächst nur für Überweisungen im Inlands-Zahlungsverkehr genutzt werden. Lastschriften sind erst mit Öffnung des E-DTA-Verfahrens der Bundesbank für EDIFACT vorgesehen. (Bilateral oder via Swift könnten erweiterte FINPAYs bereits heute problemlos genutzt werden.) Sofern der Empfänger einer Zahlung nicht EDIFACT-fähig ist, besteht eine Verpflichtung zur Weiterleitung der Angaben des Zahlungsvorgangs nur in dem Umfang, in dem diese Angaben in das DTA-Format (gemäß ZKA-Konvertierungsregeln) abbildbar sind. (Diese Einschränkung ist im Kunde-Bank-Verhältnis durch den EDI-Rahmenvertrag geregelt.) Was bedeutet "Passive EDIFACT-Fähigkeit"? Entgegennahme von FINPAY 96.A-Nachrichten für Inlands-Zahlungsverkehr von anderen Banken und LZB. Verarbeitung: Prüfung, Aufsplittung in Einzelzahlungen, Trennung von ZV-Daten und Zusatzdaten, Konvertierung der ZV-Daten in Inhouse-Format (meistens DTA) zwecks Buchung, Verrechnungseingang über EAF/ELS, Buchung, Aufbereitung der Kundeninformationen (Avise, Kontoauszüge etc.). Weiterleitung der Kundeninformation (nicht verbindlich für alle Kunden) Das Wort "passiv" ist mißverständlich. Passiv bezieht sich in diesem Zusammenhang auf die Entgegennahme der EDIFACT-Nachricht FINPAY. Diese dient den Banken zur innerbetrieblichen Verrechnung. Bei der Verarbeitung des FINPAY müssen evtl. zur Weitergabe der Zusatzinformationen wieder andere EDIFACT-Nachrichten für den Kunden erzeugt werden. Die Bank muß also hier wenn der Kunde dies wünscht evtl. bereits "aktiv" EDIFACT-Nachrichten erzeugen. Besonders problematisch ist hierbei die in der Vereinbarung festgelegte "vollumfängliche Weiterleitung" der in der EDIFACT-Nachricht enthaltenen Daten, insbesondere der Verwendungszwecke. by EDIGroup, nicht-gewerblicher Nachdruck gegen Belegexemplar gestattet. - 3/12

4 Nachdem die bestehenden Buchungssysteme nicht zur Verarbeitung umfangreicher Verwendungszwecke ausgelegt sind, und nachdem wegen der momentanen Belastung durch andere Probleme auch keine Zeit zur Verfügung steht, an diesen Systemen umfangreichere Änderungen vorzunehmen, muß die EDIFACT-Fähigkeit um die bestehenden Systeme "herumgebaut" werden. Zielsetzung ist also bei vielen Banken, die bestehenden Buchungssysteme möglichst wenig zu verändern. (Einige Großbanken sind hier bereits frühzeitig andere Wege gegangen und haben das gesamte Buchungssystem und die Kontokorrentbuchhaltung ersetzt. Für andere Banken ist der finanzielle Aufwand dafür nicht tragbar und die Zeit bis zum auch nicht ausreichend, um so eine umfassende Lösung in Angriff zu nehmen.) Ein weiteres Problem entsteht durch die momentan noch existierende Trennung von Nachrichtenübermittlung und Geldanschaffung. Mit dem Eingang eines FINPAYs steht der Bank teilweise der Gegenwert noch nicht zur Verfügung. Der eigentliche Geldeingang erfolgt dann auf dem konventionellen Verrechnungsweg (DTA). Im bilateralen Austausch wäre heute bereits eine binnenmarktübergreifende vollumfängliche Weiterleitung und Verrechnung machbar wenn die Banksysteme dazu in der Lage wären. Die Passive EDIFACT-Fähigkeit erfordert in der Bank folgende Schritte: 1. Entgegennahme von FINPAY-Nachrichten 2. Trennung und Referenzierung 3. Konvertierung 4. Buchungsfreigabe (nach Geldanschaffung und erreichtem Ausführungsdatum) 5. Buchung 6. Buchungsrückmeldung, Kundeninformation 1. Entgegennahme von FINPAY-Nachrichten Grundsätzlich sind drei verschiedene Wege möglich: Bilateral abgestimmte DFÜ-Verfahren (X.400, FTAM, FTP, SMTP, RVS) ELS über EÖ-FTAM MT121 über S.W.I.F.T. (Für den Transport von EDIFACT über HBCI existieren z.zt. noch keine Spezifikationen.) Welches Institut über welchen Weg EDIFACT-Nachrichten annimmt, wird im Interbankenband II, das von der Bundesbank erstellt und gepflegt wird, hinterlegt. Aufgrund der bestehenden Clearingwege soll der größte Teil der EDIFACT-Nachrichten bilateral ausgetauscht werden. Bei einigen Übertragungswegen bestehen schwerwiegende Einschränkungen bezüglich des Umfangs der darüber weiterleitbaren EDIFACT-Nachrichten. So ist bei der Übertragung z.b. per Telenet von der LZB die Länge einer EDIFACT-Nachricht auf Bytes begrenzt. Bei der Einbettung in eine S.W.I.F.T MT121-Nachricht gilt eine Maximallänge von Bytes. by EDIGroup, nicht-gewerblicher Nachdruck gegen Belegexemplar gestattet. - 4/12

5 2. Trennung und Referenzierung Die Banken sind verpflichtet, die in der empfangenen Nachricht enthaltenen Informationen vollständig an den Kunden weiterzugeben. Die Buchungssysteme sind aber oft nicht in der Lage, diese Daten zu verarbeiten. In diesen Fällen müssen daher alle im Inhouse-Format nicht unterzubringenden Daten vor der Konvertierung abgetrennt und separat gespeichert werden. Für die aus der Konvertierung EDIFACT/Inhouse-Format entstehenden Zusatzdaten besteht eine Weiterleitungspflicht in vollem Umfang nur für EDIFACT-fähige (und damit elektronisch erreichbare) Empfänger. Dafür muß das jeweilige Konvertersystem eine Referenznummer generieren, die einerseits in die konvertierten ZV-Daten (DTA / S.W.I.F.T.) und andererseits in die zugehörigen Zusatzdaten eingestellt wird. Die Referenznummer muß dabei so im Inhouse-Format untergebracht werden, daß sie durch das Buchungssystem unverändert durchgeleitet wird. Diese Referenznummer sollte dann über die Buchungsseite bis in den Kontoauszug (bisher MT940, später FINSTA) übernommen werden. Referenznummer meistens max.16-stellig MT940 Feld 61 Unterfeld 8 (Bankseitige Referenz) CREMUL/CREEXT Segment BGM, Kennung 1004 (Dokumenten-Nachrichtennummer) 3. Konvertierung in Inhouse-Format Für die Konvertierung der EDIFACT-Nachricht in das Inhouse-Format kann auf Konverter von inzwischen über 15 verschiedenen Anbietern zurückgegriffen werden. Die Spanne reicht dabei von kleinen (aber trotzdem leistungsfähigen) Systemen um die 20 TDM bis zu Komplettlösungen mit Messaging/Routingfähigkeit über 1 Mio. DM. Die Entscheidung muß je nach vorhandenem Inhouse- System, Anzahl der Buchungen und Anspruch der Bank und deren Firmenkunden individuell getroffen werden. Alternativ ist auch das Outsourcing der Konverterleistung möglich. Für die spätere aktive EDIFACT- Fähigkeit und Realtime-Banking wirft diese Lösung möglicherweise schwerwiegende Probleme auf. Als Übergangslösung ist sie im Moment vielerorts akzeptabel. Im Laufe der Recherchen wurde von den Autoren ein aktueller Leistungsvergleich (Stand 10/98) der verschiedenen Konverteranbieter und Outsourcer erstellt, mit dem die Eignung eines Produkts für die spezifischen Anforderungen der Banken beurteilt werden kann. Bei der Konvertierung sind die Vorgaben des EDI-Rahmenvertrags und die Empfehlungen des "Frankfurter Kreises" einzuhalten. (Z.B. bei der Behandlung von FTX/DOC-Feldern.) Das Aufsplitten einer Sammelzahlung wird von der erstbeauftragten Bank durchgeführt und ist damit für passive EDIFACT-Fähigkeit nicht erforderlich. by EDIGroup, nicht-gewerblicher Nachdruck gegen Belegexemplar gestattet. - 5/12

6 4. Buchungsfreigabe und Ausführungsdatum In einigen Fällen erfolgt im zwischenbetrieblichen Clearing eine Trennung von Nachricht und Verrechnung. Die Zahlungsverkehrsdateien werden bilateral per DFÜ oder Datenträger übermittelt. Die zugehörige Deckungszahlung (Verrechnung) erfolgt über die elektronischen Abrechnungsverfahren der Bundesbank (EAF/ELS). Es kann durchaus zu der Situation kommen, daß ein Zahlungsauftrag bereits als Nachricht vorliegt, die zugehörige Verrechnungszahlung aber noch aussteht. Umgekehrt kann auch eine Zahlung eingehen, bevor die zugehörige Nachricht eingetroffen ist. (Bei direkter Verrechnung entfallen diese Probleme.) Vor der Buchungsfreigabe muß also möglicherweise der Zahlungseingang abgewartet werden. Dies kann zu Verzögerungen bei der Weiterleitung von zeitkritischen Zahlungen und bei der Erzeugung von Avisen führen. Bei einem vorhandenen Realtime-Buchungssystem stellt sich hier zusätzlich die Frage, wie lange auf das Eintreffen der Verrechnungszahlung gewartet werden soll, bevor aufwendige Nachforschungen eingeleitet werden. Bei batchorientierten Systemen stellen sich derartige Fragen weniger. Die Referenzierung zwischen FINPAY-Nachricht und Zahlungseingang ist zudem eine weitere Schwachstelle, bei der es zu Pannen kommen kann. Nachdem inzwischen bereits auf normalen Überweisungsformularen auch Ausführungsdaten bis zu 14 Tage in die Zukunft angegeben werden können (z.b. Deutsche Bank), muß die Bank den Kundenauftrag evtl. mehrere Tage speichern, bis das Ausführungsdatum erreicht ist. Bei zunehmender Nutzung dieses neuen Features muß mit erheblichem Speicherplatzbedarf für diese Zwischenspeicherung gerechnet werden. Noch problematischer wird dies bei der in EDIFACT-Nachrichten möglichen Angabe eines Valutadatums. Hier muß die Bank für die rechtzeitige Weiterleitung sorgen, damit der Betrag termingerecht auf dem Empfängerkonto eintrifft. Zusammen mit der gewünschten maximalen Ausnutzung der Floatzeit bedeutet das für die Bank, daß sie die externe Laufzeit eines Zahlungsauftrags möglichst genau kalkulieren muß. Die Optimierung der Leitwege muß an diese neuen Gegebenheiten angepaßt werden. 5. Buchung Wie oben bereits angesprochen, wird bei der hier vorgestellten Lösung der gesamte EDIFACT-Bereich um das bestehende Buchungssystem herumgebaut. Die Änderungen am bestehenden System sind damit minimal. by EDIGroup, nicht-gewerblicher Nachdruck gegen Belegexemplar gestattet. - 6/12

7 6. Buchungsrückmeldung, Kundeninformation Zur Zeit liefern viele Banken ihren Kunden Avise, Vormerkposten und Kontoauszüge auf elektronischem Weg z.b. als MT940/41/42. Für die geforderte "vollumfängliche" Weiterleitung der Zusatzdaten bieten sich folgende Lösungen an: für EDIFACT-fähige Kunden: Als EDIFACT-Nachricht CREADV, CREMUL, CREEXT, DEBADV, DEBMUL für nicht EDIFACT-fähige (aber elektronisch erreichbare) Kunden: Textfile, Versand per DFÜ, oder evtl. sogar als Fax. Die Weiterleitung der Zusatzdaten kann erfolgen: ohne Rückmeldung vom Buchungssystem aufgrund einer Rückmeldung vom Buchungssystem Weiterleitung ohne Buchungsrückmeldung (Avis) Direkt nach Eingang der FINPAY-Nachricht und Konvertierung in Inhouse-Format werden parallel die Zusatzdaten in CREMUL/CREEXT/Textfile umgewandelt (gemäß Einstellung in den Stammdaten) und an den Kunden versandt. Vorteil: Zeitgewinn für den Kunden Problem: Sollte eine Buchung nicht möglich sein, bekommt der Kunde ggf. Avise zu Eingängen, die nicht gebucht werden. Rechtlich verbindlich ist letztendlich erst der Kontoauszug. Weiterleitung nach Buchungsrückmeldung Vorteil: Der Kunde erhält sofort den verbindlichen Kontoauszug. Probleme: Alle Kunden, für die keine Avise erstellt werden, bekommen die Zusatzdaten mit Verzögerung von bis zu einem Tag. (Batchbetrieb) Die Kunden erhalten keine Infos über nicht gebuchte Umsätze Zusätzliche Stammdatenkennzeichen Auch, wenn man die bestehenden Systeme möglichst wenig verändern will, sind in der Stammdatenbank zur Ablaufsteuerung zusätzliche Kennzeichen über die Wünsche und die EDIFACT- Fähigkeit der Kunden notwendig. Der Aufwand für die Integration dieser Angaben in die bestehende Datenbank und der zukünftig entstehende erhöhte Pflegeaufwand für by EDIGroup, nicht-gewerblicher Nachdruck gegen Belegexemplar gestattet. - 7/12

8 Rückrufe Nachdem bei der passiven EDIFACT-Fähigkeit in den FINPAY-Nachrichten ausschließlich Überweisungen möglich sind und noch keine anderen EDIFACT-Nachrichtentypen genutzt werden, ist ein Rückruf nur nach der alten DTA-Methode möglich. Datenschutz und Datensicherheit Für die Authentisierung der Nachrichten existieren folgende Varianten: Begleitzettel (Papier oder per Fax) BCS-EU AUTACK Begleitzettel Prinzipiell besteht bei allen Übertragungsverfahren die Möglichkeit, die Autorisierung über einen (gefaxten) Begleitzettel durchzuführen. Dies ist nur als Übergangslösung akzeptabel. Für eine schnelle automatische Abwicklung sollten in Zukunft elektronische Verfahren favorisiert werden. verfügbare DFÜ-Verfahren mit EU: BCS-FTAM BCS-FTP MCDFÜ AUTACK Sobald die EDIFACT-Nachricht AUTACK endgültig vom ZKA verabschiedet ist, soll dieser Nachrichtentyp für die Absicherung verwendet werden. Bei der Übertragung per DFÜ ist zu bedenken, daß die EU oder später die AUTACK eine reine Signatur darstellen, und daß der eigentliche Nachrichteninhalt weiterhin für jedermann lesbar im Klartext übertragen wird. Eine hochwertige Verschlüsselung ist anzustreben. Zukünftig werden sensible Kundendaten in noch größerem Umfang als jetzt über Datennetze transportiert werden. Die im Moment fast ausschließlich praktizierte unverschlüsselte Übertragung dieser Daten kann man nur als sträflichen Leichtsinn bezeichnen. Es ist als sicher anzunehmen, daß auch die als "sicher" geltenden geschlossene Netze wie z.b. Telebox/X.400, Datex-P etc. einem technisch versierten Angreifer keinen nennenswerten Widerstand leisten können. Die Umstellung auf EDIFACT-Nachrichten bietet eine Gelegenheit, hier parallel auch eine wirksame Datenverschlüsselung einzuführen, um Wirtschaftsspionage in großem Umfang vorzubeugen. Hierfür eignen sich z.b. die bekannten Public-Key-Verfahren (RSA, Diffie-Hellman). Für den Datenaustausch by EDIGroup, nicht-gewerblicher Nachdruck gegen Belegexemplar gestattet. - 8/12

9 mit Ländern, in denen durch gesetzliche Regelungen der Einsatz hochwertiger kryptographischer Verfahren beschränkt ist, bietet sich CaWeb an. Die Banken versprechen sich für die Zukunft aufgrund flexibler Dienstleistung eine verstärkte Geschäftszuweisung und eine Konzentration in- und für verschiedene Länder. Damit besteht trotz hochwertig gesicherter Übertragungswege für den Kunden die Gefahr, daß er mit seiner Geschäftstätigkeit in nicht immer gewünschter Weise transparenter für die Bank wird (Kreditlinien, Fusionen von Mitbewerbern etc.) Dies stärkt nicht immer die Entscheidung, mit einer Bank auch europaweit zu arbeiten. by EDIGroup, nicht-gewerblicher Nachdruck gegen Belegexemplar gestattet. - 9/12

10 Ausblick: Aktive EDIFACT-Fähigkeit Zusätzliche Anforderungen gegenüber passiver EDIFACT-Fähigkeit: Bearbeiten von: (PAYORD), PAYEXT, PAYMUL, DIRDEB FINCAN Erzeugen/Weiterleiten von: FINPAY FINSTA, DEBADV, DEBMUL, CREADV, CREEXT, CREMUL BOPxxx Später auch: AUTACK, BANSTA, CONTRL, DOCxxx Zusätzlicher Aufwand: Entgegennahme von EDIFACT-Nachrichten verschiedener Versionen vom Kunden Sämtliche DFÜ-Wege müssen EDIFACT-fähig gemacht werden. Konvertierung Zusatzaufwand: Neue Mappings. Mögliche Routing-/Messagingaufgaben. Höhere Auslastung des Konvertersystems, d.h. evtl. Hardwareaufrüstung erforderlich. Versand von EDIFACT-Nachrichten Die Nachrichtentypen FINPAY, FINSTA, DEBMUL und CREMUL müssen erzeugt und versendet werden. Dadurch entsteht für die Bank ein erhöhter Aufwand für die Unterhaltung zusätzlicher DFÜ-Leitungen und evtl. Kosten für den Nachrichtenversand über Fremdanbieter. Zusätzliche Möglichkeit: Banken als Dienstleister für Tochterunternehmen und kleinere Kreditinstitute Der Konverter kann nach Implementierung der für aktive EDIFACT-Fähigkeit nötigen Nachrichtentypen auch für das Angebot von weiteren Dienstleistungen genutzt werden: Entgegennahme und Aufbereitung von FINPAY für andere Banken Umwandlung und Inhouse-Formatbildung für normierte/spezifizierte Interbankformate Formatkonvertierungen für Industrie und Handel by EDIGroup, nicht-gewerblicher Nachdruck gegen Belegexemplar gestattet. - 10/12

11 Printcenter (Option E-Post) Voraussetzung: Mandantenfähiges System (Billing von DFÜ, Konvertierung, Ausdruck etc.) In diesem Zusammenhang möchten wir neben Banken (und virtuellen Banken) auf Near-Banks (Kreditkartenunternehmen, Onlineprovider etc.) sowie NONBANKS (Walmart, Tesco, Siemens etc.) hinweisen. Diese Gruppen sind durch EDIFACT und WebEDI in der Lage, Geschäftsvorgänge mit Zahlungsverkehr optimiert zu nutzen und anzubieten. Volle aktive EDIFACT-Fähigkeit & Realtime-Banking Wie bereits oben angedeutet, sind hierfür Erweiterungen der Stammdatenbank um zusätzliche Merkmale erforderlich. Für Realtime-Banking sind in der Regel auch Änderungen im internen Ablauf notwendig, da die Daten der verschiedenen Systeme ständig untereinander abgeglichen werden müssen, um Korrespondenzbanken und Kunden jederzeit eine aktuelle Kontostandsauskunft bieten zu können. Die Leitwegoptimierung für Standard- und Eilzahlungen wirft bei Realtime-Banking auch eine Reihe zusätzlicher Probleme auf. Letztendlich würde aber durch die konsequente Echtzeitfähigkeit der Bank die Erzeugung und der Versand von Belastungs- und Gutschriftsanzeigen entfallen, so daß am Ende eine spürbare Arbeitserleichterung zu erwarten wäre. Eine vollständige Umsetzung dieser Ideen ist erst nach Jahr-2000-Umstellung, Euro-Einführung und allgemeiner Verbreitung von EDIFACT realistisch. Die Verfügbarkeit dieser Dienstleistung ist ein Alleinstellungsmerkmal, daß künftig bei der Wahl der "Europäischen Bank" sicher nicht zu vernachlässigen ist. Die Erstellung eines Konzept für diese Thematik sollte unter strategischer Sicht frühzeitig in Angriff genommen werden. Ausblick Durch Bankfusionen, erweiterten elektronischen Geschäftsdatenaustausch via EDIFACT (Handels-, Zahlungs-, Gesundheits- und vorgangsintegrierte Daten) wird sich vieles ändern. Ob neue globale Netzdienstleistungen, sicherere und preiswertere (biometrische) Sicherungsverfahren oder WebEDI hier die treibende Kraft seien werden bleibt abzuwarten. Der Kunde im Binnenmarkt ob Kleinunternehmer, Mittelständler oder Großkonzern entscheidet sich nach klaren Kosten- und Nutzengesichtpunkten für den leistungsfähigsten Partner seiner Wahl. Von den Autoren sind weitere Publikationen zu den Themen Financial-EDIFACT, strategische Domains, Beratung und Produktentwicklungen im internationalem Electronic-Banking erschienen. Kontakt für weitere Informationen und Projektanfragen: Tel: Fax: by EDIGroup, nicht-gewerblicher Nachdruck gegen Belegexemplar gestattet. - 11/12

12 Anforderungen an die Banken / Zahlungsverkehrsdienstleister / virtuelle Payfactory. 1. Sichere Einlieferung (zuverlässig und hochwertig verschlüsselt) 2. Kostengünstige und fristgerechte Weiterleitung 3. Nutzung des weltweit verbindlichen EDIFACT-Formates 4. Rückmeldung und Empfangsquittungen 5. Einfache Unterschriftsleistung (evtl. mit biometrischen Verfahren) 6. Revisionssicherheit, katastrophenfallsichere Archivierung EDIFACT-Anforderung an die Clearingpartner: 1. "vollumfängliche" Entgegennahme der UN-EDIFACT-Formate 2. Realtime-Buchung 3. internationale Leitwegsteuerung 4. Geldanschaffung/Gegenwert zeitgleich mit oder in einer EDI-Nachricht 5. Anschluß an Clearingzentralen und elektronische Abrechnungssysteme (TARGET etc.) Anforderung an Unternehmen: 1. EDIFACT-Formate müssen eingeliefert werden (aus FiBu oder Erfassungsprogramm) oder Konvertierungshilfen (Übergang vom Inhouse-Format in EDIFACT) 2. Einlieferungswege wie IP, X.400, ggf. FTAM und andere Protokolle und Sicherungs- / Authorisierungsverfahren. 3. Empfang der EDIFACT-Nachrichten FINSTA, CREEXT, CREMUL, DEBxxx 4. Darstellung der Zins- / Valutensalden für das Euro-Cashmanagement etc. 5. Nutzung der "vollumfänglichen" Bankdaten zum automatischen Abgleich in der jeweiligen Buchhaltung. Kontakt für weitere Informationen und Projektanfragen: info@edigroup.de Tel: Fax: by EDIGroup, nicht-gewerblicher Nachdruck gegen Belegexemplar gestattet. - 12/12