E Anlage 26 EFM vHGS-Vertrag_mAnl_Muster_Stand 211001_MVU 211206.pdf

[Seite 1]

vHGS-Vertrag

Vertrag

über die

Nutzung, Teilnahme und Zusammenarbeit am

verbundweiten mandantenfähigen Hintergrundsystem

(vHGS) des eTicket RheinMain

zwischen der

Rhein-Main-Verkehrsverbund GmbH Alte Bleiche 5 Hofheim am Taunus

• nachstehend auch „RMV“ genannt -

und

…………. …………. ………….

• nachstehend auch „Teilnehmer“ oder beide gemeinsam „Vertragspartner“ genannt -

[Seite 2]

Versionsverwaltung

21-10-01 vHGS-Vertrag Seite 2 von 11

[Seite 3]

Inhalte

Präambel § 1 Gegenstand des Vertrages § 2 Vertragspartner § 3 Aufgaben des RMV § 4 Aufgaben des Teilnehmers § 5 Nutzungsbedingungen vHGS § 6 Vertragsänderungen § 7 Teilnehmerversammlung, Stimmrechte, Beschlussfassung § 8 Anwenderkreise § 9 Betriebskosten vHGS § 10 Datenschutz § 11 Vertraulichkeit § 12 Haftung § 13 Aufnahme neuer Teilnehmer § 14 In-Kraft-Treten, Laufzeit, Kündigung § 15 Schlussbestimmungen

Anlagen

Anlage 1: Regelwerk vHGS Anlage 2: Beschreibung vHGS Anlage 3: Konzept Externe Mandanten – Bidirektionale Schnittstelle Anlage 4: Liste mit Teilnehmern nach Aufgabenbereich Anlage 5: Glossar Anlage 6: Auszug aus dem Vertrag über die Teilnahme am (((eTicket-Deutschland - (((eTicket-Teilnahmevertrag mit dem auf die Rhein-Main-Verkehrsverbund GmbH spezifizierten Migrationsszenario

21-10-01 vHGS-Vertrag Seite 3 von 11

[Seite 4]

Präambel

Die Rhein-Main-Verkehrsverbund GmbH (RMV) hat zum Fahrplanwechsel 2011/2012 im RMV-Gebiet mit der flächendeckenden Einführung eines Elektronischen Fahrgeldmanagements (EFM) begonnen und in den letzten Jahren gemeinsam mit den Partnern im RMV auf Basis einer einvernehmlichen Grundlage, vertrauensvoll und erfolgreich umgesetzt.

Als ein kundengerechtes und effizientes Vertriebssystem soll das EFM langfristig die Einnahmen erhöhen und Potentiale zur Kostensenkung schaffen.

Kernelement dieses Vertriebssystems ist das verbundweite Hintergrundsystem (vHGS), welches eine koordinierte Abwicklung aller vertrieblichen Prozesse des EFM ermöglicht und auf dessen Basis die Teilnehmer eine gemeinsame Kundenbetreuung durchführen ("Service durch Dritte") können (ausgenommen der Aufgabenbereich JobTicket).

§ 1 Gegenstand des Vertrages Gegenstand dieses Vertrages ist die Festlegung von Rechten und Pflichten der Vertragspartner für die Nutzung des vHGS im Tarif-Anwendungsgebiet des RMV.

Die Anlagen 1 bis 6 sind Vertragsbestandteil. Im Fall von Widersprüchen geht die Vereinbarung zur gemeinsamen Verantwortung für die Datenverarbeitung nach Art. 26 DSGVO (Joint Controllership-Vereinbarung) den Regelungen des Vertrages und sonstigen Anlagen vor.

§ 2 Vertragspartner (1) Durch diesen Vertrag wird zwischen den Vertragspartnern ein bilaterales Vertragsverhältnis begründet. Eine Ausnahme hierzu stellt die Vereinbarung gemäß Artikel 26 DSGVO (Joint Controllership-Vereinbarung) zwischen den Teilnehmern und gegebenenfalls eingesetzten verantwortlichen Vertriebsdienstleistern dar (vgl. Absatz 4 und § 10). Diese begründet nach dem Willen der Vertragspartner ein multilaterales Vertragsverhältnis zwischen den Teilnehmern. (2) Zwischen den Vertragspartnern wird durch Abschluss dieses Vertrages kein gesellschaftsrechtliches Verhältnis und hieraus entstehende Rechte und Pflichten begründet, weder zwischen den Teilnehmern untereinander noch zwischen den Teilnehmern und dem RMV. (3) Voraussetzung zur Teilnahme am vHGS ist der Abschluss dieses Vertrages sowie eines Vertrages über die Teilnahme am (((eTicket-Deutschland „(((eTicket-Teilnahmevertrag“ mit der VDV-Kernapplikations GmbH & Co.KG, Köln (VDV-KA KG). Dabei sind die vom RMV gewählten Migrationsschritte Ausbauvariante 2a gemäß „Vertrag über die Teilnahme am (((eTicket-Deutschland – (((eTicket-Teilnahmevertrag mit dem auf die Rhein-Main-Verkehrsverbund GmbH spezifizierten Migrationsszenario“ (vgl. Anlage 6) Mindestvoraussetzung für den Teilnehmer.

21-10-01 vHGS-Vertrag Seite 4 von 11

[Seite 5]

Über den Abschluss des (((eTicket-Teilnahmevertrages des Teilnehmers ist ein Nachweis an den RMV zu erbringen. Für den Nachweis reicht die Übersendung einer Kopie der ersten und letzten Seite des unterzeichneten Vertrages über die Teilnahme am (((eTicket- Deutschland „(((eTicket-Teilnahmevertrag“, die die Vertragspartner sowie Unterschrift der Beteiligten und Datum erkennen lässt. (4) Soweit der Teilnehmer nach § 4 Absatz 3 den/die Aufgabenbereich/e Online vHGS (inkl. Service durch Dritte), Vertrieb JobTicket (ohne Service durch Dritte), TicketShop, Vertrieb & Service (Bidi II) wahrnimmt, ist weitere Voraussetzung zur Teilnahme am vHGS der Abschluss der multilateralen Vereinbarung zur gemeinsamen Verantwortung für die Verarbeitung personenbezogener Daten nach Art. 26 DSGVO (Joint Controllership- Vereinbarung). Die Vereinbarung regelt die Rechte und Pflichten der Teilnehmer und findet auf alle Tätigkeiten Anwendung, bei denen Beschäftigte der Vertragsparteien oder durch sie beauftragte Auftragsverarbeiter personenbezogene Daten für die Verantwortlichen verarbeiten. Über den Teilnehmer eingesetzte verantwortliche Vertriebsdienstleister (VDL, vgl. § 3 Abs. 5) sind ebenfalls dazu verpflichtet, die Joint Controllership-Vereinbarung, abzuschließen.

§ 3 Aufgaben des RMV (1) Der RMV übernimmt die in diesem Vertrag benannten Aufgaben. Im vHGS nimmt der RMV die KA-Rolle des Produktverantwortlichen (PV), wie sie sich aus § 1 (((eTicket- Teilnahmevertrag ergibt, ein. (2) Der RMV ist Eigentümer des vHGS und ist verantwortlich für die fachliche und technische Betriebsführung. Der RMV stellt das vHGS zur Nutzung durch die Teilnehmer bereit. Der RMV richtet für die Teilnehmer eine vHGS-Informationsplattform (Ordner) auf einer gemeinsamen Webanwendung ein. In diesem Ordner werden durch den RMV sämtliche Dokumente hinterlegt, die Bestandteile dieses Vertrages sind (Anlagen) und solche, die sich aus Informationsverpflichtungen dieses Vertrages ergeben. (3) Der RMV betreibt, aktualisiert und pflegt die vHGS-Informationsplattform. Der RMV ermöglicht den Teilnehmern ein Leserecht durch Zugang zur vHGS- Informationsplattform. Die Zugangsdaten sowie Informationen zur Anwendung erhält der Teilnehmer durch die vom RMV-Dienstleister (übergeordnete fachliche Betriebsführung (üfb-vHGS)) versandte Bestätigungs-E-Mail auf Anfrage des Teilnehmers (§ 4 Abs. 7). (4) Der RMV koordiniert die Zusammenarbeit der Teilnehmer im vHGS nach Maßgabe dieses Vertrages und pflegt auf der vHGS-Informationsplattform eine Liste mit allen Teilnehmern am vHGS (vgl. Anlage 4). (5) Der RMV ist berechtigt zur Erfüllung seiner Leistungen Subunternehmer und verantwortliche Vertriebsdienstleister (VDL) über Verkehrsunternehmen einzusetzen. Die Teilnehmer werden über die Beauftragung von Subunternehmern und verantwortlichen VDL sowie deren Namen und Adresse auf der vHGS-Informationsplattform aktuell informiert. Die Verantwortung des RMV gegenüber den Teilnehmern für die in diesem Vertrag eingegangenen Pflichten wird durch die Beauftragung von Subunternehmern und verantwortlichen VDL nicht berührt.

§ 4 Aufgaben des Teilnehmers (1) Der Teilnehmer ist entweder interner oder externer Mandant. Ein interner Mandant ist ein Teilnehmer, der für seine Vertriebstätigkeit das vHGS einsetzt. Ein externer Mandant ist ein Teilnehmer, der ein eigenes Vertriebssystem einsetzt (vgl. § 5 Abs. 4). (2) Der Teilnehmer übernimmt im vHGS die KA-Rolle des Kundenvertragspartners (KVP) und/oder des Dienstleisters (DL), wie sie sich aus § 1 (((eTicket-Teilnahmevertrag ergibt.

21-10-01 vHGS-Vertrag Seite 5 von 11

[Seite 6]

(3) Dem Teilnehmer sind folgende vHGS Aufgabenbereiche zugeordnet:

Interner Mandant

o Online vHGS (inkl. Service durch Dritte)

o Vertrieb JobTicket (ohne Service durch Dritte)

o Offline vHGS

o TicketShop

o Kontrolle

Externer Mandant

o KA Datenaustausch (Bidi I)

o Vertrieb & Service (Bidi II)

o Kontrolle

(Der entsprechende vHGS Aufgabenbereich ist anzukreuzen; ein Teilnehmer kann auch mehrere Aufgabenbereiche übernehmen.) (4) Die Aufgabenbereiche sind näher in Anlage 1 „Regelwerk vHGS“ unter Punkt 4 (interne Mandanten) und Punkt 5 (externe Mandanten) definiert. (5) Der Teilnehmer hat für die Einhaltung der Anforderungen aus dem Regelwerk vHGS entsprechend seiner Aufgabenbereiche Sorge zu tragen. (6) Der Teilnehmer ist berechtigt, zur Erfüllung seiner Leistungen Subunternehmer und in Absprache mit dem RMV verantwortliche Vertriebsdienstleister (VDL) einzusetzen. Der RMV ist über die Beauftragung sowie Namen und Adressen der Subunternehmer zu informieren, der diese auf der vHGS-Informationsplattform in Form einer ständig zu aktualisierenden Liste veröffentlicht. Die Verantwortung des Teilnehmers gegenüber dem RMV für die in diesem Vertrag eingegangenen Pflichten wird durch die Beauftragung von Subunternehmern nicht berührt. (7) Um einen Zugang zur vHGS-Informationsplattform zu erhalten, hat sich der Teilnehmer unter Angabe seiner Kontaktdaten (Name und Adresse des Unternehmens, Name und Vorname des Ansprechpartners, E-Mai-Adresse, Telefonnummer) an die übergeordnete fachliche Betriebsführung (üfb-vHGS) – E-Mail-Adresse vhgs.ufb@rms-consult.de – zu wenden. (8) Der Teilnehmer ist ferner berechtigt, auch Vertriebsdienstleister (VDL) einzusetzen, die die Datenverarbeitung selbständig als Verantwortlicher im datenschutzrechtlichen Sinne wahrnehmen und insoweit allein die Verantwortung für die Verarbeitung der Daten und die daraus erwachsenden datenschutzrechtlichen Pflichten, wie z. B. die Wahrnehmung der Rechte gegenüber Betroffenen, tragen. (9) Der datenschutzrechtlich eigenverantwortliche VDL wird vom Teilnehmer legitimiert das vHGS zu nutzen und nimmt die dem Teilnehmer im vHGS zugeordneten und die vom Teilnehmer an den VDL übergebenen Aufgabenbereiche wahr. Die datenschutzrechtliche Verantwortung für die wahrgenommenen Aufgabenbereiche ist in der Joint Controllership-Vereinbarung geregelt.

21-10-01 vHGS-Vertrag Seite 6 von 11

[Seite 7]

§ 5 Nutzungsbedingungen vHGS (1) Allen Teilnehmern wird das vHGS-System mit folgenden Komponenten ohne Lizenzkosten zur Nutzung gemäß dieses Vertrages zur Verfügung gestellt:  vHGS,  Reporting-Tool Oracle Application Express (APEX),  Kartenleser-Dienstprogramm. (2) Durch die Teilnahme am vHGS erwerben die Teilnehmer weder vHGS- Systemkomponenten noch über diesen Vertrag hinausgehende Nutzungsrechte. Soweit zur Erfüllung ihrer vertraglichen Pflichten gegenüber dem RMV, gegenüber anderen Teilnehmern oder gegenüber den Kunden darüber hinaus außerhalb des vHGS-Systems befindliche (bei externen Mandanten) oder vHGS-systemfremde Komponenten, Lizenzen oder Rechte erforderlich sind, haben sich die Teilnehmer erforderliche Komponenten, Lizenzen oder Rechte daran zu beschaffen. (3) Die Nutzung des vHGS ist grundsätzlich nur im Tarif-Anwendungsgebiet des RMV innerhalb der in § 4 Abs. 3 festgelegten Aufgabenbereiche gestattet. Eine Nutzung darüber hinaus ist mit dem RMV im Einzelfall abzustimmen. (4) Die zusätzliche Nutzung eines eigenen Hintergrundsystems/Vertriebssystems ist möglich, soweit hierdurch die Funktionalität des vHGS und die verbundweiten Kontrollprozesse nicht beeinträchtigt werden. Die Voraussetzungen zur Nutzung eines eigenen Hintergrundsystems sind im Regelwerk vHGS beschrieben (vgl. Anlage 1, Kapitel 5). Ist die ergänzende Nutzung eines eigenen Systems vorgesehen, ist der RMV darüber rechtzeitig vor Betriebsstart zu informieren. Es gelten die Rahmenbedingungen der Anlage 3 dieses Vertrages. Hierdurch entstehende zusätzliche Kosten trägt der jeweilige Teilnehmer selbst. (5) Der RMV oder ein von ihm beauftragter Dritter ist Ansprechpartner für die Belange, die sich aus der Nutzung des vHGS ergeben. Der Ansprechpartner wird auf der vHGS- Informationsplattform veröffentlicht. Kann das vHGS nicht vertragsgemäß genutzt werden, ist entsprechend Kapitel 2 und 3 des Regelwerks vHGS zu handeln (siehe Anlage 1). (6) Der Teilnehmer ist berechtigt zur Erfüllung seiner Leistung Subunternehmer einzusetzen.

§ 6 Vertragsänderungen (1) Jeder Teilnehmer kann schriftlich ausführlich begründete und wesentliche Vorschläge zur Einleitung eines Vertragsänderungsverfahrens beim RMV einreichen, soweit diese seine Rechte und Pflichten betreffen1. Dem RMV steht für Änderungen des Vertrages ein Initiativrecht zu. (2) Sollten nach Prüfung der Vorschläge (Absatz 1) durch den RMV Änderungen dieses Vertrages erforderlich sein, werden diese den Teilnehmern rechtzeitig, spätestens drei Monate vor Wirksamwerden, schriftlich mitgeteilt. (3) Bei Änderungen, die eine Anpassung der technischen Systeme der Vertragspartner bedürfen, wird nach Abstimmung mit den betroffenen Vertragspartnern durch den RMV eine Umsetzungsfrist festgelegt und diese bei der Vertragsänderung berücksichtigt. (4) Vertragsänderungen gelten für den jeweiligen Teilnehmer als genehmigt, sofern dieser nicht innerhalb von acht Wochen nach Eingang der schriftlichen Nachricht gegen den entsprechenden Änderungsvorschlag schriftlich Einspruch erhebt. (5) Im Falle eines Einspruchs wird der RMV nach Ablauf der Einspruchsfrist innerhalb von acht Wochen, jedoch frühestens nach 3 Wochen, eine Teilnehmerversammlung einberufen, um eine Entscheidung über den von dem Einspruch betroffenen

1 Ausdrücklich ausgenommen davon sind Änderungen, die aufgrund von Tarifanpassungen oder sonstigen RMV-Gremienbeschlüssen erfolgen müssen. 21-10-01 vHGS-Vertrag Seite 7 von 11

[Seite 8]

Änderungsvorschlag herbeizuführen. Die Entscheidung erfolgt entsprechend dem in § 7 definierten Verfahren. (6) Das Einspruchsrecht des Teilnehmers ist gemäß seiner datenschutzrechtlichen Verantwortung auf die wahrgenommenen Aufgabenbereiche im vHGS beschränkt. Die datenschutzrechtliche Verantwortung ist in der Joint Controllership-Vereinbarung geregelt.

§ 7 Teilnehmerversammlung, Stimmrechte, Beschlussfassung (1) Die Teilnehmerversammlung setzt sich aus allen Vertragspartnern des vHGS-Vertrages zusammen. (2) Je Vertragspartner kann maximal ein Vertreter teilnehmen. Einem vom Vertragspartner eingesetzten VDL steht ein Gastrecht zu, an der Teilnehmerversammlung teilzunehmen. Ein Stimmrecht besitzt ausschließlich der Vertragspartner des vHGS-Vertrags. (3) Vorsitz und Organisation der Teilnehmerversammlung sowie Dokumentation der Versammlung und aller gefassten Beschlüsse werden durch den RMV wahrgenommen. Die Durchführung der Versammlungen und die Art und Weise der Beschlussfassungen unterliegt keinen bestimmten Vorgaben. Beschlüsse können nach freiem Ermessen des RMV insbesondere auch schriftlich im Umlaufverfahren, durch Brief, Telefax, E-Mail, mündliche oder fernmündliche, insbesondere in Telefon- und/oder Videokonferenzen oder jeweils in Kombination dieser Verfahren gefasst werden. Der RMV als Organisator der Teilnehmerversammlung ist berechtigt mit mehreren Personen teilzunehmen, stimmberechtigt ist ein Vertreter des RMV. Dritte, die nicht Vertragspartner oder eingesetzte VDL der Vertragspartner sind, können grundsätzlich nicht teilnehmen. Ausnahmen kann die Teilnehmerversammlung auf Antrag zu Beginn einer Sitzung mit einfacher Mehrheit zulassen, wenn es sachliche Gründe hierfür gibt (z. B. fachtechnischer Vortrag, Vertretung durch einen übergeordneten Verband etc.). (4) Im Übrigen kann jeder Vertragspartner einen anderen Vertragspartner mit der Vertretung seiner Interessen in der Teilnehmerversammlung bevollmächtigen. (5) Die Teilnehmerversammlung ist beschlussfähig, sofern sie mit der vereinbarten Frist einberufen wurde (vgl. § 6 Abs. 5) und mindestens 50 % stimmberechtigte Vertreter der Vertragspartner anwesend sind oder entsprechende Vollmachten vorliegen. (6) Der Umfang der Stimmrechte je Vertragspartner ergibt sich aus der Anzahl der Aufgaben des Teilnehmers gemäß § 4. Je Aufgabenbereich erhält jeder Vertragspartner eine Stimme. Der RMV erhält eine Stimme für jeden Aufgabenbereich. Zu Beginn der Teilnehmerversammlung legt der RMV eine aktuelle Liste der Stimmrechtsverteilung vor. (7) Die Stimmabgabe erfolgt durch Handzeichen, die abgegebene Entscheidung wird mit der Anzahl der Stimmen des Vertragspartners multipliziert. In den Fällen des § 7 Abs. 4 wird der Vertreter zur erneuten Stimmabgabe gesondert aufgefordert. Die Auszählung der Stimmen erfolgt unmittelbar nach Abgabe aller Stimmen und wird noch in der Teilnehmerversammlung verkündet. (8) Ein Beschluss gilt als angenommen, wenn mindestens 75% JA-Stimmen vorliegen. (9) Der RMV erhält eine „Sperrminorität“ von 25,01% im Verhältnis zu den jeweils in einer Teilnehmerversammlung vertretenen Stimmen. Ohne Zustimmung des RMV ist eine Entscheidung in jedem Fall nicht möglich. Beschlüsse werden allen Vertragspartnern durch den RMV innerhalb von zwei Wochen nach Ende der Teilnehmerversammlung übersandt. (10) Die Teilnehmerversammlung wird nur einberufen, wenn Beschlussvorlagen vorliegen.

21-10-01 vHGS-Vertrag Seite 8 von 11

[Seite 9]

§ 8 Anwenderkreise (1) Gemäß den Aufgabenbereichen nach § 4 Abs. 3 werden Anwenderkreise gebildet, die sich nach Bedarf treffen. Bei Themenüberschneidungen können die Anwenderkreise gemeinsam tagen. Die Termine der Anwenderkreise werden allen Teilnehmern gemäß den nach § 4 Abs. 3 übernommenen Aufgabenbereichen mit Vorlauf von 4 Wochen bekannt gegeben. Die Anwenderkreise haben folgende Aufgaben:  Ermittlung von grundsätzlichem/n Änderungsbedarf/-wünschen,  Ermittlung von Bedarf an neuen Funktionen bzw. ggf. Abschaffung von Funktionen,  Erörterung/Diskussion zu ggf. vorliegenden Einzelfallproblemen,  Fachlicher Austausch der Anwender untereinander (2) Die Anwenderkreise werden vom RMV organisiert und moderiert. Das Ergebnis der jeweiligen Veranstaltung ist schriftlich zu fixieren und den Teilnehmern zur Verfügung zu stellen. (3) Die Anwenderkreise haben keine Beschlussrechte.

§ 9 Betriebskosten vHGS Die Teilnahme am vHGS ist für die Teilnehmer kostenfrei.

§ 10 Datenschutz (1) Die Teilnehmer sowie die eingesetzten VDL haben die Regelungen der EU- Datenschutzgrundverordnung (DSGVO) und des Bundesdatenschutzgesetzes (BDSG) in der jeweils gültigen Fassung einzuhalten. (2) Die Rechte und Pflichten der Teilnehmer sowie der eingesetzten VDL bei der gemeinsamen Verarbeitung personenbezogener Daten sind in der Joint Controllership- Vereinbarung geregelt (vgl. § 2 Abs. 4). Diese Joint Controllership-Vereinbarung findet auf alle Tätigkeiten Anwendung, bei denen Beschäftigte der Teilnehmer oder der eingesetzten VDL oder durch sie beauftragte Auftragsverarbeiter personenbezogene Daten verarbeiten.

§ 11 Vertraulichkeit (1) Die Vertragspartner verpflichten sich, sämtliche vertraulichen, geschäftlichen Informationen die ihnen im Zusammenhang mit der Vertragsabwicklung bekannt werden, vertraulich zu behandeln und ausschließlich für Zwecke des Vertrages zu verwenden. Diese Beschränkung gilt nicht für Informationen, die nachweislich zum Zeitpunkt der Überlassung öffentlich oder den Vertragspartnern bereits bekannt waren oder nach Überlassung an die Vertragspartner veröffentlicht werden, ohne dass ein Vertragspartner dies zu vertreten hätte. Die Vertragspartner stehen dafür ein, dass die Bestimmungen dieser Vertraulichkeitsklausel auch von ihren Angestellten, Erfüllungsgehilfen und Beratern beachtet werden. (2) Die Vertragspartner unterrichten sich unverzüglich, wenn sie von einem Gericht, einer Behörde oder einem Dritten aufgefordert werden, solche vertraulichen Informationen mitzuteilen. Die Vertraulichkeitsverpflichtung gilt nicht, wenn ein Vertragspartner kraft Gesetzes oder aufgrund einer gerichtlichen oder behördlichen Verfügung vertrauliche Informationen offenlegen muss, oder der andere Vertragspartner sich ausdrücklich mit einer Offenlegung einverstanden erklärt. (3) Vertrauliche Informationen sind alle Informationen eines Vertragspartners, die entsprechend gekennzeichnet sind oder deren Vertraulichkeit sich aus der Natur der Sache oder den Umständen ergibt, unabhängig davon, ob diese verkörpert sind oder nicht.

21-10-01 vHGS-Vertrag Seite 9 von 11

[Seite 10]

(4) Die vorstehenden Pflichten gelten auch nach Kündigung oder Ablauf dieses Vertrages drei Jahre lang fort.

§ 12 Haftung (1) Die Vertragspartner haften untereinander für Vorsatz und grobe Fahrlässigkeit in vollem Umfang. (2) Im Falle einfach fahrlässigen Handelns haften die Vertragspartner ausschließlich für  Personenschäden,  Schäden, für die die Vertragspartner aufgrund zwingender gesetzlicher Vorschriften (z. B. nach dem Produkthaftungsgesetz) einzustehen haben sowie  Schäden wegen der Verletzung von wesentlichen Pflichten, die die Erreichung des Zwecks des Vertrages gefährden bzw. deren Erfüllung die ordnungsgemäße Durchführung des Vertrages erst ermöglichen und auf die der andere Vertragspartner regelmäßig vertrauen darf (Kardinalpflichten). (3) Im Falle der Verletzung von Kardinalpflichten ist die Haftung für einfach fahrlässiges Handeln auf vertragstypische und bei Abschluss des jeweiligen Vertrages vorhersehbare Schäden begrenzt. (4) Gemäß Art. 82 DSGVO können Haftungsansprüche gegenüber allen datenschutzrechtlich Verantwortlichen wahrgenommen werden. Die Haftung der gemeinsam Verantwortlichen ist in der Joint Controllership-Vereinbarung geregelt (vgl. § 2 Abs. 4).

§ 13 Aufnahme neuer Teilnehmer Sollten besondere Umstände eintreten, die die Aufnahme eines neuen Teilnehmers erfordern, kann der RMV unter den Voraussetzungen des § 2 dieses Vertrages weitere Teilnehmer zulassen. Besondere Umstände sind insbesondere dann gegeben, wenn durch  Ausschreibung,  Insolvenz,  Kommerzielle Verkehre eine Neuaufnahme von Teilnehmern erforderlich ist. Bei Neuaufnahme eines Teilnehmers wird dies durch Änderung der Anlage 4 auf der vHGS- Informationsplattform dokumentiert.

§ 14 In-Kraft-Treten, Laufzeit, Kündigung (1) Der Vertrag tritt mit Unterzeichnung in Kraft sofern der Vertragspartner bereits den Teilnahmevertrag zum (((eTicket-Deutschland (vgl. § 2 Abs. 3) sowie die Joint Controllership-Vereinbarung (soweit nach § 2 Abs. 4 erforderlich) abgeschlossen hat. Wird einer der oder beide anderen genannten Verträge (Teilnahmevertrag zum (((eTicket-Deutschland oder die Joint Controllership-Vereinbarung) zeitlich später unterzeichnet, so tritt dieser Vertrag zeitgleich mit dem zuletzt gezeichneten Vertrag in Kraft. (2) Der Vertrag hat eine unbestimmte Laufzeit. Der Vertrag kann frühestens nach Ablauf von zwei Jahren seit der Aufnahme des Betriebes mit einer Kündigungsfrist von einem Jahr zum Ende eines jeden Kalenderjahres schriftlich gekündigt werden. (3) Der Vertrag kann ferner von beiden Vertragsparteien gekündigt werden, wenn ein Teilnehmer nicht mehr im RMV-Tarifanwendungsgebiet tätig sein kann und keine Aufgaben gemäß § 4 Abs. 3 wahrnimmt sowie mit der Beendigung der Teilnahme am (((eTicket- Deutschland (vgl. § 2 Abs. 3) oder mit der Beendigung der Joint Controllership-Vereinbarung (soweit nach § 2 Abs. 4 erforderlich). Der Teilnehmer hat dies dem RMV unverzüglich mitzuteilen. 21-10-01 vHGS-Vertrag Seite 10 von 11

[Seite 11]

Die Kündigung nach Satz 1 hat schriftlich mit einer Frist von drei Monaten zum Jahresende zu erfolgen. Beide Parteien bemühen sich, soweit dies möglich ist, vor der Kündigung des Vertrages einen Kompromiss zu suchen. (4) Das Recht auf außerordentliche Kündigung aus wichtigem Grund bleibt unberührt. Ein wichtiger Grund liegt insbesondere vor, wenn die Joint Controllership-Vereinbarung (soweit nach § 2 Abs. 4 erforderlich) nicht unterschrieben ist oder sonstige Umstände eintreten, die geeignet sind, erhebliche Schäden bei anderen Teilnehmern hervorzurufen oder die Systemintegrität wesentlich zu beeinflussen. (5) Der Teilnehmer kann den Vertrag jederzeit ohne Einhaltung einer Frist kündigen, wenn ein schwerwiegender Verstoß des RMV gegen Datenschutzvorschriften oder die Bestimmungen dieses Vertrages und seiner Anlagen vorliegt, der RMV eine Weisung des Teilnehmers nicht ausführen kann oder will oder der RMV Kontrollrechte des Teilnehmers vertragswidrig verweigert. Insbesondere die Nichteinhaltung der in diesem Vertrag und seinen Anlagen vereinbarten und aus Art. 26 DSGVO (Joint Controllership- Vereinbarung, soweit nach § 2 Abs. 4 erforderlich) abgeleiteten Pflichten stellt einen Verstoß dar. (6) Bei Kündigung regelt sich die Rückgabe der personenbezogenen Daten nach der Joint Controllership-Vereinbarung, soweit nach § 2 Abs. 4 erforderlich.

§ 15 Schlussbestimmungen (1) Sollten in diesem Vertrag einzelne Bestimmungen rechtsunwirksam sein oder werden, so sind sich die Vertragspartner darüber einig, dass dadurch die Gültigkeit der übrigen Bestimmungen nicht beeinträchtigt werden soll. Die unwirksame Bestimmung ist durch eine rechtswirksame Regelung zu ersetzen, die dem wirtschaftlichen Zweck der unwirksamen Bestimmung am nächsten kommt. Dasselbe gilt, wenn bei Durchführung dieses Vertrages eine ergänzungsbedürftige Regelungslücke offenbar wird. (2) Änderungen dieses Vertrages bedürfen der Schriftform. Dies gilt auch für die Änderung des Schriftformerfordernisses. (3) Ausschließlicher Gerichtsstand für alle Streitigkeiten, die aus diesem Vertrag resultieren, ist Frankfurt am Main.

Hofheim, den Ort Datum Rhein-Main-Verkehrsverbund GmbH Teilnehmer

Prof. Knut Ringat, Geschäftsführer und Sprecher der Geschäftsführung

Dr. André Kavai, Geschäftsführer

21-10-01 vHGS-Vertrag Seite 11 von 11

[Seite 12]

Regelwerk vHGS

Regelwerk vHGS eTicket RheinMain

Anlage 1 zum vHGS-Vertrag

[Seite 13]

Versionsverwaltung

21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 2 von 19

[Seite 14]

Inhaltsverzeichnis Seite

1 Einleitung 4

2 Support 4 2.1 Fehler oder Betriebsstörungen 4 2.2 Optimierung, Weiterentwicklung oder nicht zeitkritische Probleme 4 2.3 vHGS-Informationsplattform 5 2.4 Bedarf an Chipkarten und Bestandteilen des KA- Sicherheitsmanagements 5

3 Ansprechpartner 5

4 Regeln für interne Mandanten 5 4.1 Aufgabenbereich Online vHGS (inkl. Service durch Dritte) 5 4.1.1 Vertrieb und Service für eigene Kunden 5 4.1.2 Vertrieb und Service für Fremdkunden (Service durch Dritte) 7 4.2 Aufgabenbereich Offline vHGS 11 4.3 Aufgabenbereich TicketShop 11 4.4 Aufgabenbereich Kontrolle 11 4.5 Aufgabenbereich Vertrieb JobTicket ohne Service durch Dritte 12

5 Regeln für externe Mandanten 13 5.1 Service durch Dritte 13 5.2 Kontrolle und Verkauf 13 5.3 Internetvertrieb 14 5.4 Kontrolle 14

6 Online-Kundenportal meinRMV 14

7 Gemeinsame Kundenstammdatenbank (RMV- Kundenstammdatenbank) – voraussichtlich ab Herbst 2021 produktiv 15 7.1 Einleitung 15 7.2 Systemübersicht 16 7.3 Akteure 18

21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 3 von 19

[Seite 15]

1 Einleitung

Zur Abwicklung des elektronischen Fahrgeldmanagements im RMV (eTicket Rhein- Main) nutzen die Teilnehmer oder von Teilnehmern eingesetzte und legitimierte Ver- triebsdienstleister (VDL) gemeinsam das verbundweite Hintergrundsystem (vHGS). Je nach Tätigkeit im Verbund übernimmt jeder Teilnehmer bzw. jeder eingesetzte VDL einen oder mehrere Aufgabenbereiche (vgl. § 4 vHGS-Vertrag), zu denen die in Kapitel 4 und 5 beschriebenen Aufgaben und Leistungen gehören.

Teilnehmer, die für ihre Vertriebstätigkeiten das vHGS einsetzen, werden im Folgen- den auch interne Mandanten genannt. Teilnehmer, die gemäß § 5 Abs. 4 vHGS-Ver- trag ein eigenes Vertriebssystem einsetzen, werden im Folgenden auch externe Man- danten genannt.

Die in diesem Dokument beschriebenen Aufgaben und Leistungen gelten in der Folge gleichermaßen für die Teilnehmer als auch für die von den Teilnehmern eingesetzten VDL.

2 Support

Unabhängig vom Aufgabenbereich, stehen den Teilnehmern folgende Supportmög- lichkeiten zur Verfügung:

2.1 Fehler oder Betriebsstörungen

Bei Fehlern oder Betriebsstörungen, die bei der Nutzung des vHGS auftreten, steht die übergeordnete technische Betriebsführung (ütB) an 7 Tagen rund um die Uhr (24/7) zur Verfügung. In der Zeit zwischen 17:00 Uhr und 09:00 Uhr ist telefonisch Kontakt mit der ütB aufzunehmen. Auf Meldungen, die per Telefon oder E-Mail erfol- gen können, wird ein Mitarbeiter der ütB spätestens nach 15 Minuten reagieren. Dies gilt sowohl für die Bürozeiten Montag bis Freitag von jeweils 9:00 bis 17:00 Uhr als auch für den außerhalb der Bürozeiten organisierten Bereitschaftsdienst.

2.2 Optimierung, Weiterentwicklung oder nicht zeitkritische Probleme

Wenn Bedarf an Optimierung oder Weiterentwicklung des vHGS besteht, oder nicht zeitkritische Probleme auftreten, ist dies der übergeordneten fachlichen Betriebsfüh- rung (üfB) per Telefon oder E-Mail zu melden. Die üfB steht von Montag bis Freitag von jeweils 9:00 bis 17:00 Uhr zur Verfügung. Die gemeldeten Änderungswünsche werden von der üfB gesammelt und mit dem Teilnehmer, der den Bedarf angemeldet hat, abgestimmt. Sollten von dem Änderungswunsch mehrere Teilnehmer betroffen sein, erfolgt die Abstimmung im entsprechenden Anwenderkreis (vgl. § 8 vHGS-Ver- trag).

21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 4 von 19

[Seite 16]

2.3 vHGS-Informationsplattform

Zur umfassenden Kommunikation zwischen allen Teilnehmern/VDL, dem RMV, der ütB und der üfB steht eine webbasierte vHGS-Informationsplattform zur Verfügung. Hierüber werden Informationen kommuniziert, Dokumente und Software vorgehalten und verteilt1.

2.4 Bedarf an Chipkarten und Bestandteilen des KA-Sicherheitsmanage- ments

Die Beschaffung der Chipkarten sowie der Bestandteile des KA-Sicherheitsmanage- ments (SAMs, Schlüsselmaterial, etc.) erfolgt durch und über den RMV. Seinen Bedarf meldet der Teilnehmer der üfB.

3 Ansprechpartner

Um die Kommunikation sicherzustellen, ist von allen Teilnehmern, dem RMV, der ütB und der üfB mindestens ein Ansprechpartner mit E-Mailadresse und optional einer Te- lefonnummer zu benennen. Die Ansprechpartner des RMV, der ütB und der üfB wer- den auf der vHGS-Informationsplattform veröffentlicht.

4 Regeln für interne Mandanten

4.1 Aufgabenbereich Online vHGS (inkl. Service durch Dritte)

4.1.1 Vertrieb und Service für eigene Kunden

Mitarbeiterbedienter Vertrieb und Service (vHGS-Webanwendung)

Interne Mandanten führen Verkaufs- und Serviceprozesse für Kunden, bei denen sie selber Vertragspartner sind oder werden (im Folgenden „eigene Kunden“ genannt), gemäß den jeweils gültigen „Gemeinsamen Beförderungsbedingungen und Tarifbe- stimmungen (GBB)“ sowie den „Besonderen Bedingungen“ über die Webanwendung des vHGS aus.

Kundenbedienter Service (Online über meinRMV2)

Im Rahmen der Einführung des eTicket RheinMain können eigene Kunden bestimmte Serviceleistungen auch online über „meinRMV“ durchführen. Der dadurch generierte Handlungsbedarf beim internen Mandanten wird im Aufgaben- management des vHGS zur Bearbeitung bereitgestellt.

Die kundenbedienten Serviceleistungen über meinRMV lassen sich in zwei Kategorien unterteilen. Zum einen in die Leistungen, die nach Eingabe des Kunden in „meinRMV“ und Übergabe in das vHGS automatisiert ablaufen (Online - Kategorie A) und zum

1 Mit Abschluss des vHGS-Vertrages erhalten die Teilnehmer den Zugang zur vHGS-Informationsplatt- form. 2 RMV-Online-Kundenportal, vgl. Kapitel 6 21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 5 von 19

[Seite 17]

anderen in die Leistungen, die einen Handlungsbedarf des internen Mandanten aus- lösen (Online - Kategorie B).

Serviceleistungen Online - Kategorie A

 Änderung der räumlichen Gültigkeit (bar)  Änderung zu einer anderen Fahrkartenart (bar)  Erneute Erzeugung von bei der Ausgabe des Nutzermediums erzeugten Begleit- dokumenten  Erneute Erzeugung von bei der Ausgabe von Berechtigungen erzeugten Begleit- dokumenten  Registrieren von Nutzermedien  Änderung von Kundenstammdaten inklusive Änderung der Bankverbindung (Abo)

Serviceleistungen Online - Kategorie B

Dem internen Mandant werden über das Aufgabenmanagement des vHGS die nach- gelagerten Aufgaben, die durch eigene Kunden Online über „meinRMV“ ausgelöst wurden, zur Bearbeitung bereitgestellt.

 Anforderung einer Ersatzausstellung eines Nutzermediums  Änderung der räumlichen Gültigkeit (Abo)  Änderung zu einer anderen Fahrkartenart (Abo)

Abwicklung des Zahlungsverkehrs Zur Abwicklung von Zahlungen stellt der RMV eine Bezahlplattform bereit. Der Betrieb der Bezahlplattform erfolgt durch den RMV oder einen von ihm beauftragten Dritten. Um einen reibungslosen Abrechnungsprozess zu gewährleisten ist der interne Man- dant verpflichtet die folgenden Leistungen zu erfüllen:

 Die zur Abrechnung erforderlichen Girokonten sind bei einer Bank in Deutsch- land zu unterhalten. Die entsprechenden Kontodaten sind an den RMV oder den von ihm benannten Dritten (=Betreiber der Bezahlplattform) weiterzuleiten. Der interne Mandant hat seine Bank darauf hinzuweisen, dass ein zu benen- nender Dritter und seine Subunternehmer in seinem Auftrag Daten zur Abrech- nung mit in den Bankgiroverkehr eingeben (offene Stellvertretung). Der interne Mandant erteilt seiner Bank die Erlaubnis, dass ein zu benennender Dritter und dessen Subunternehmer in seinem Auftrag über den in die Abwicklung des Be- zahlverfahrens eingeschalteten Partner Zahlungsinformationen aus dem Konto auslesen dürfen.  Es ist ein Vertrag über die Bereitstellung einer technischen Schnittstelle zum elektronischen Datentransfer und weitere Leistungen mit einem Partner abzu- schließen. Es ist zu regeln, dass der RMV oder ein von ihm beauftragter Dritter im Auftrag Abrechnungsdaten über diese Schnittstelle übermittelt, damit diese dann über die verschiedenen zu beteiligenden Institute die Belastung der End- kundenkonten und die Gutschrift auf dem Konto des jeweiligen internen Man- danten automatisiert anstoßen kann.

21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 6 von 19

[Seite 18]

 Der interne Mandant lässt sich von seinem Endkunden sofern dieser per elekt- ronischen Lastschriftverkehr bezahlen möchte, ein entsprechendes SEPA- Mandat erteilen.

Für Abrechnungen über Kreditkarten:

 Der interne Mandant ist verpflichtet, einen Kreditkartenakzeptanzvertrag über die Abwicklung von Forderungen aus der Akzeptanz von Kreditkarten (VISA und Mastercard) mit einem Kreditkarten-Akquirer abzuschließen und die rele- vanten Vertragsdaten an den RMV oder den von ihm benannten Dritten weiter- zugeben. Der interne Mandant hat seinen Kreditkarten-Akquirer darauf hinzu- weisen, dass der RMV oder der von ihm benannte Dritte und dessen Subunter- nehmer in seinem Auftrag Daten zur Abrechnung mit den Endkunden in das System des Partners eingeben (offene Stellvertretung).

4.1.2 Vertrieb und Service für Fremdkunden (Service durch Dritte)

Mit dem Ziel der Steigerung der Qualität und Kundenorientierung können im Rahmen des Services rund um das eTicket RheinMain an personalbedienten Verkaufsstellen (pVks) Leistungen für dritte Kundenvertragspartner (KVP), die ebenfalls den Aufga- benbereich Online vHGS ausfüllen, durchgeführt werden. Ausgenommen davon sind die lokal subventionierten Tarifprodukte, JobTickets sowie Schülerticket Hessen, die über den Schulwegkostenträger ausgegeben werden.

Zugriff auf Fremdkundendaten für Serviceleistungen durch Dritte

Für die Durchführung der Serviceleistungen bearbeitet der Dritte die personenbezoge- nen Daten des Fremdkunden im Auftrag des vertragsführenden internen Mandanten. Die Erlaubnis erhält der Dritte im Einzelfall jeweils dadurch, dass a) der Fremdkunde das Nutzermedium zur Nutzung für die Authentifizierung vor- legt (gilt für Servicefälle A5, A6 und A7) oder b) bei vorhandenem oder fehlendem Nutzermedium sich durch Angabe personen- bezogener Daten unter Vorlage eines geeigneten Lichtbildausweises authenti- fiziert (gilt für Servicefälle der Kategorie A, die nicht Ziffer a) unterliegen). Mit dem Zugriff auf die personenbezogenen Datenbereiche des Fremdkunden, bestä- tigt der Dritte das Vorliegen der Erlaubnis. Hierfür ist jedem Zugriff auf Fremdkunden- daten eine Meldung des vHGS vorgeschaltet, die bestätigt werden muss, was im vHGS protokolliert wird. Ein Zugriff auf Daten des vertragsführenden internen Man- danten unter Umgehung dieser Funktion ist untersagt. Der vertragsführende interne Mandant kann die von Dritten aufgenommenen Serviceleistungen und durchgeführten Datenzugriffe monatlich in einem Report abrufen. In einem zweiten Report werden monatlich die für andere interne Mandanten durchgeführten Serviceleistungen doku- mentiert.

21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 7 von 19

[Seite 19]

Leistungen im Service durch Dritte

Die Serviceleistungen lassen sich in zwei Kategorien unterteilen. Zum einen in die Leistungen, die abschließend über das vHGS abgewickelt werden können (Service durch Dritte - Kategorie A), und zum anderen in die Leistungen, die neben der Eingabe im vHGS eine Weiterleitung von vom Kunden quittierten Dokumenten an den vertrags- führenden internen Mandanten erfordern (Service durch Dritte – Kategorie B).

Serviceleistungen durch Dritte - Kategorie A

Bei Serviceleistungen der Kategorie A ist eine Eingabe in das vHGS erforderlich.

A1. Registrieren von Nutzermedien (Zugriffserlaubnis nur gemäß Ziffer b) Nicht registrierte, vom vHGS ausgegebene Nutzermedien sind auf Wunsch des Kun- den nachträglich im vHGS zu registrieren, d.h. die Kundenstammdaten sind entspre- chend aufzunehmen und im vHGS einzugeben.

A2. Änderung von Kundenstammdaten (Zugriffserlaubnis nur gemäß Ziffer b) Die Kundenstammdaten sind auf Wunsch des Kunden zu ändern und/oder zu ergän- zen. Davon ausgenommen ist die Änderung einer Bankverbindung.

A3 Sperrung der Applikation bei Verlust eines registrierten Nutzermediums (Zugriffs- erlaubnis nur gemäß Ziffer b) Auf Wunsch des Kunden ist bei Verlust/Diebstahl eines registrierten Nutzermediums die Applikation zu sperren. Die durch den Mitarbeiter eines Dritten erzeugte Sperran- forderung, wird dem vertragsführenden internen Mandanten über das Aufgabenma- nagement des vHGS zur Prüfung vorgelegt und muss von diesem freigegeben werden.

A4 Ersatzausstellung eines Nutzermediums (Zugriffserlaubnis nur gemäß Ziffer b) Auf Wunsch des Kunden ist bei Verlust/Diebstahl/Defekt eines Nutzermediums ein Er- satz-Nutzermedium auszugeben. Das gilt sowohl für Nutzermedien mit übertragbarer als auch persönlicher Fahrberechtigung. Ein Ersatz kann für alle registrierten Nutzer- medien erfolgen. Ein Ersatz für anonyme Nutzermedien kann nur unter Vorlage der beim Erwerb ausgehändigten Original-Quittung erfolgen. Sollten sich auf dem zu er- setzenden Nutzermedium von externen Mandanten ausgegebene Fahrtberechtigun- gen befinden, ist der Kunde zu informieren, dass diese Fahrtberechtigungen beim ent- sprechenden externen Mandanten ersetzt werden3. An der GUI des vHGS wird dies dem Mitarbeiter angezeigt.

A5 Kündigung der ÖPV-Applikation (Zugriffserlaubnis gemäß Ziffer a) Der Kunde kann seine ÖPV-Applikation kündigen, sofern keine gültige Fahrberechti- gung mehr auf der Applikation vorhanden ist und er das Nutzermedium gleichzeitig zurückgibt. Bei Kündigung erfolgt eine Löschung der ÖPV-Applikation inkl. der dazugehörigen Kundendaten. Das Nutzermedium ist einzuziehen.

3 Das gilt für alle Hintergrundsysteme externer Mandanten, die noch nicht über die Bidirektionale Schnitt- stelle (Bidi II) mit dem vHGS verknüpft sind. Die Ersatzausstellung kann in diesem Fall nur durch den externen Mandanten erfolgen. 21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 8 von 19

[Seite 20]

A6 Annahme von gefundenen Nutzermedien (Zugriffserlaubnis gemäß Ziffer a) Das Nutzermedium ist entgegenzunehmen. Im Falle eines registrierten Nutzermedi- ums, für das noch kein Ersatz ausgestellt wurde, ist mit dem Inhaber des Nutzermedi- ums Kontakt aufzunehmen und mit ihm abzustimmen, wie mit dem Nutzermedium wei- ter verfahren werden soll. Im Falle eines anonymen Nutzermediums ist die Applikation zu sperren und das Nutzermedium einzuziehen.

A7 Prüfung auf gültige Fahrkarte für die Erstattung von Ersatzfahrkarten bei defektem bzw. nicht-lesbaren Nutzermedium (Zugriffserlaubnis gemäß Ziffer a) Wer beim Einstiegsversuch in den Bus ein nicht lesbares Ticket hat, muss eine „Er- satz“-Fahrkarte lösen. Das ist eine Einzelfahrkarte mit aufgedruckter/beschriebener NM-Nummer. Der Mitarbeiter in der Vertriebsstelle muss das Vorhandensein einer gül- tigen Fahrtberechtigung auf dem nicht-lesbaren Nutzermedium im vHGS prüfen und dem Kunden bestätigen4. In diesem Zusammenhang wird das Nutzermedium ersetzt. Geld für Ersatzfahrkarte wird durch üfB erstattet.

A8 Prüfung auf gültige Fahrkarte für die Klärung eines EBE-Falles bei defektem bzw. nicht-lesbaren Nutzermedium (Zugriffserlaubnis nur gemäß Ziffer b) Wenn ein Erhöhtes Beförderungsentgelt (EBE) wegen eines nicht lesbaren Nutzerme- diums ausgestellt wird, soll dieses niedergeschlagen werden, wenn eine Fahrtberech- tigung vorhanden war. Der Mitarbeiter in der Vertriebsstelle muss das Vorhandensein einer gültigen Fahrtberechtigung auf dem nicht-lesbaren Nutzermedium im vHGS prü- fen und dem Kunden bestätigen5. In diesem Zusammenhang wird das Nutzermedium ersetzt.

A9 Erneute Erzeugung von bei der Ausgabe des Nutzermediums erzeugten Begleit- dokumenten (Zugriffserlaubnis nur gemäß Ziffer b) Wenn an den Kunden wegen eines nicht lesbaren Nutzermediums mit vorhandener Fahrtberechtigung ein neues Nutzermedium ausgegeben wird, können Begleitdoku- mente nachträglich als PDF-Dokument aufgerufen oder neu erstellt werden.

A10 Erneute Erzeugung von bei der Ausgabe von Berechtigungen erzeugten Begleit- dokumenten (Zugriffserlaubnis nur gemäß Ziffer b) Werden Nutzerdaten (Vorname, Nachname oder Geburtsdatum) oder Berechtigungs- nachweise angepasst bzw. geändert, muss im Anschluss ebenfalls eine Synchronisa- tion der Chipkarte durchgeführt werden. Begleitdokumente können nachträglich als PDF-Dokument aufgerufen oder neu erstellt werden.

Infolge der beschriebenen Serviceprozesse eingezogene Nutzermedien sind zu sam- meln und halbjährlich an die „übergeordnete fachliche Betriebsführung“ (üfb) des vHGS zu versenden. Die Nutzermedien werden bei der üfb in einem nur für ausge- wählte Personen zugänglichen Tresor gesammelt und in regelmäßigen Zeitabständen fachmännisch vernichtet.

Serviceleistungen durch Dritte - Kategorie B

Bei Serviceleistungen der Kategorie B sind nach der Eingabe ins vHGS immer zusätz- lich die entsprechenden Eingaben, Änderungen, Aktualisierungen etc. auszudrucken

4 Das Bestätigungsformular ist auf der vHGS-Informationsplattform zu finden. 5 Das Bestätigungsformular ist auf der vHGS-Informationsplattform zu finden. 21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 9 von 19

[Seite 21]

und vom Kunden zu unterschreiben. Der Kunde bestätigt damit die Korrektheit und Vollständigkeit der Eingaben. Die Belege sind bis zum 11. des Vormonats an den ver- tragsführenden internen Mandanten per Fax, gemäß der im vHGS hinterlegten Kon- taktliste zu übersenden.

Die nachgelagerten Aufgaben werden dem vertragsführenden internen Mandanten im Aufgabenmanagement des vHGS bereitgestellt.

Der vertragsführende interne Mandant kann - wie bei Kategorie A - über das vHGS einen Report über Eingaben, Änderungen und Aktualisierungen, die von Dritten durch- geführt wurden, abrufen.

B1 Änderung der räumlichen Gültigkeit (Abo) Die Änderung der räumlichen Gültigkeit einer Fahrberechtigung im Abo ist auf Wunsch des Kunden im System zur weiteren Verarbeitung zu erfassen. Der durch Dritte aufgenommene Änderungswunsch wird dem vertragsführenden inter- nen Mandanten über das Aufgabenmanagement des vHGS angezeigt. Der vertrags- führende interne Mandant hat den Änderungswunsch zu prüfen und bei positivem Er- gebnis bis zum 25. des Vormonats über das Aktionsmanagement dem Kunden als Aktion bereit zu stellen. Der Kunde ist über das Ergebnis der Prüfung vor dem 25. des Vormonats schriftlich zu informieren.

B2 Änderung zu einer anderen Fahrkartenart (Abo) Die Änderung zu einer anderen Fahrkartenart ist auf Wunsch des Kunden im System zur weiteren Verarbeitung zu erfassen. Ausgenommen ist die Änderung von einer übertragbaren zu einer persönlichen Fahrkartenart. Der durch Dritte aufgenommene Änderungswunsch wird dem vertragsführenden internen Mandanten über das Aufga- benmanagement des vHGS angezeigt. Der vertragsführende interne Mandant hat den Änderungswunsch zu prüfen und bei positivem Ergebnis bis zum 25. des Vormonats über das Aktionsmanagement dem Kunden als Aktion bereit zu stellen. Der Kunde ist über das Ergebnis der Prüfung vor dem 25. des Vormonats schriftlich zu informieren.

21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 10 von 19

[Seite 22]

4.2 Aufgabenbereich Offline vHGS

Die Ausgabe von Nutzermedien und Verkäufe von Fahrberechtigungen sind prinzipiell auch offline zum vHGS über Busdrucker und stationäre Fahrausweisautomaten mög- lich.

Folgende Voraussetzungen sind für den Offline-Verkauf zu erfüllen:  Als Offline-Verkaufsgeräte sind KA-zertifizierte Geräte mit einem SAM einzu- setzen. Für die an das vHGS gemeldeten Applikations- und Berechtigungsaus- gaben verwenden die Offline-Verkaufsgeräte die gemeinsamen KVP-Schlüssel des eTicket RheinMain.  Die Berechtigungsnummernkreise werden auf Nachfrage über die üfB zur Nut- zung zur Verfügung gestellt.  Der interne Mandant betreibt ein Terminalmanagementsystem mit einer Schnitt- stelle gemäß vHGS-Pflichtenheft PH06-02 (das Pflichtenheft ist in der vHGS- Informationsplattform veröffentlicht), das die KA-Transaktionsdaten der Ver- kaufsgeräte sammelt und an das vHGS täglich weiterleitet.  Das Terminalmanagementsystem bezieht täglich zu einer abgestimmten Zeit Sperr- und Aktionslisten vom vHGS (vgl. Kap. 4.4) und aktualisiert die Verkaufs- geräte ebenfalls täglich vor der ersten Nutzung mit den Sperr- und Aktionslisten.  Das Terminalmanagementsystem bezieht Zertifikate und Kryptogramme von der üfB und verteilt diese an die Verkaufsgeräte. Der interne Mandant ist ange- halten mittelfristig Verkaufsgeräte im Einsatz zu haben, die in der Lage sind, die Zertifikate und Kryptogramme KA-konform in die SAMs zu laden.

4.3 Aufgabenbereich TicketShop

Für die Abwicklung des internetbasierten Vertriebs von RMV-Fahrkarten über den RMV-TicketShop setzt der RMV über einen vHGS-Teilnehmer einen legitimierten Ver- triebsdienstleister (auch VDL-Online genannt) ein. Der VDL-Online ist für alle Fahrkar- tenbestellungen, die im RMV-TicketShop durch meinRMV-Kunden oder Gastbestel- lungen vorgenommen werden, im Vertriebssystem „vHGS“ bearbeiten und damit für die Zustellung der Fahrkarten an den Kunden sorgen. Der VDL-Online ist verantwort- licher Vertriebsdienstleister eines Kundenvertragspartners (KVP).

Für den Aufgabenbereich TicketShop gelten die Regeln des Aufgabenbereiches On- line vHGS (inkl. Service durch Dritte) aus Kapitel 4.1.

Die Bereitstellung des Vertriebskanals „RMV-TicketShop“ auf www.rmv.de erfolgt durch den RMV.

4.4 Aufgabenbereich Kontrolle

Interne Mandanten mit dem Aufgabenbereich Kontrolle gewährleisten die Erfüllung fol- gender Leistungen im Rahmen des vHGS:

1. Das unternehmenseigene Terminalmanagementsystem ist mit einer Schnitt- stelle zum vHGS auszustatten, um den Austausch von Sperr- und Aktionsliste,

21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 11 von 19

[Seite 23]

sowie von Sperr- und Transaktionsnachweisen sicherzustellen. Die Schnitt- stelle zum vHGS ist im vHGS-Pflichtenheft PH06-02_Terminalmanagementsys- teme beschrieben und in der vHGS-Informationsplattform veröffentlicht. 2. Die Sperrlisten, die im vHGS um 00:30 Uhr bereitgestellt werden, sind täglich auf allen im Unternehmen eingesetzten Kontrollgeräten6 zu aktualisieren. 3. Sofern Kontrollgeräte für die Ausgabe von Aktionen im Aktionsmanagement vorgesehen sind, muss die Aktionsliste, die im vHGS um 00:30 Uhr bereitge- stellt wird, täglich auf den entsprechenden Kontrollgeräten aktualisiert werden. 4. Die aufgrund der Kontrolltätigkeit entstehenden Sperrnachweise sowie ggf. Transaktionsnachweise aus dem Aktionsmanagement, sind mindestens einmal täglich an das vHGS zu übertragen. Nachweise, die bis 22:00 Uhr übertragen werden, werden im Rahmen der Erstellung der Sperr- und Aktionslisten des Folgetages berücksichtigt. 5. Die aufgrund der Kontrolltätigkeit entstehenden Kontrollnachweise sind täglich an das vHGS zu übertragen.

4.5 Aufgabenbereich Vertrieb JobTicket ohne Service durch Dritte

Teilnehmer mit dem Aufgabenbereich Vertrieb JobTicket ohne Service durch Dritte sind für die Ausgabe und Verwaltung von JobTickets zuständig bzw. unmittelbar ge- genüber dem JobTicketunternehmen berechtigte Verkehrsunternehmen. Dabei nutzen Teilnehmer das vHGS alleine für die Verwaltung und Ausgabe von JobTickets an die Mitarbeiter eines JobTicketunternehmens, gegenüber denen Teilnehmer bezüglich der einzelnen an die Nutzer ausgegebenen Fahrkarten in der Rolle als Kundenvertrags- partner (KVP) auftreten. Sofern weitere Produkte des eTicket RheinMain durch die Teilnehmer verkauft und verwaltet werden, geschieht dies außerhalb des vHGS. Im vHGS besteht grundsätzlich kein Zugriff seitens der Teilnehmer auf die Daten der Mit- arbeiter des JobTicketunternehmens. Dies gilt sowohl für die Ausgabe als auch für die Verwaltung der JobTickets durch die Teilnehmer. Lediglich die Namen und Email-Ad- ressen der vHGS-Administratoren auf Seiten der JobTicketunternehmen sind den Teil- nehmern bekannt, da diese die Administratoren anlegen müssen (s. u., Punkt 3).

Die Teilnehmer gewährleisten die Erfüllung folgender Leistungen:

1. JobTicketunternehmen, die direkt mit den JobTicketprozessen im vHGS starten oder vom elektronischen Auskunfts- und Druckprogramm (eAD) auf das vHGS migrieren, werden durch das betreuende VU fachlich, organisatorisch und schu- lungstechnisch unterstützt.
2. Für jedes JobTicketunternehmen muss der Teilnehmer im vHGS eine Unter- nehmenseinheit anlegen, die insoweit die maßgebliche Vertriebsstelle reprä- sentiert, über die die vom JobTicketunternehmen mit der Ausgabe und Verwal- tung des JobTickets betrauten Mitarbeiter ihre Aufgaben wahrnehmen können.
3. Um den zuvor genannten Mitarbeitern im JobTicketunternehmen den erforder- lichen Zugang zum vHGS zu verschaffen, legt das betreuende Verkehrsunter- nehmen ein Benutzerkonto für den Administrator im JobTicketunternehmen an. Alle weiteren Benutzerkonten kann dieser Administrator selbst anlegen und ver- walten. Diese selbst angelegten Benutzerkonten haben allerdings keine Admi- nistratorrechte.

6 Kontrollgeräte: Busdrucker, Einstiegskontrollterminal, mobiles Kontrollgerät 21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 12 von 19

[Seite 24]

4. Dem JobTicketunternehmen ist ein Bestand an Chipkartenrohlingen und ggfs. Wertmarkenbögen zur Verfügung zu stellen. Diese (Chipkartenrohlinge) wer- den benötigt, um per Schreib-/Leseeinheit JobTickets für neue Mitarbeiter und Ersatzchipkarten ausstellen zu können. Wenn der Erstversand nicht über den Massenpersonalisierer erfolgt (<50 JobTickets), werden die Chipkartenrohlinge bereits bei der Erstausgabe benötigt. Weiterhin kann das JobTicketunterneh- men auch laufend Rohlinge beim VU nachbestellen.
5. Der Teilnehmer (Verkehrsunternehmen) stellt seinen JobTicketunternehmen eine monatliche Rechnung auf Basis der dazu nötigen Meldung der Berechtig- ten und übernimmt im Folgenden das Forderungsmanagement.

5 Regeln für externe Mandanten

Die Kommunikation und der Datenaustausch zwischen internen Mandanten im vHGS und externen Mandanten erfolgt über die Schnittstelle „vHGS / Externe Mandanten – Bidirektionale Schnittstelle“ (siehe Anlage 3).

Die bidirektionale Schnittstelle besteht aus zwei Teilen:  KA Datenaustausch (Bidi I: Kontrolle und Verkauf)  Vertrieb & Service (Bidi II: Service durch Dritte und Internetvertrieb).

5.1 Service durch Dritte

Die Ausübung der Serviceleistungen im Service durch Dritte über ein eigenes KA-zer- tifiziertes Vertriebs- und Abosystem erfolgt gemäß den Regeln und der technischen Spezifikation der Anlage 3 (vHGS / Externe Mandanten - Bidirektionale Schnittstelle – Kapitel 4).

5.2 Kontrolle und Verkauf

Der Austausch von KA-Transaktionen im Kontext von Kontrollen und Verkäufen von Fahrtberechtigungen über ein eigenes KA-zertifiziertes Kontroll-, Vertriebs- und Abo- system erfolgt gemäß den Regeln und der technischen Spezifikation der Anlage 3 (Ka- pitel 5).

Im Rahmen des Aufgabenbereichs Kontrolle und Verkauf ist sicherzustellen, dass durch einen externen Mandanten keine Dauerberechtigungen auf eine Chipkarte eines internen Mandanten ausgegeben werden7.

7 Die umgekehrte Regel „ein interner Mandant darf kein Abo-Produkt auf eine Chipkarte eines externen Mandanten ausgeben“ ist technisch im vHGS umgesetzt und muss daher nicht im Aufgabenbereich 4.1 geregelt werden. 21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 13 von 19

[Seite 25]

5.3 Internetvertrieb

Die kundenbediente Ausübung der Serviceleistungen über ein eigenes Internetportal in Verbindung mit einem eigenen KA-zertifiziertem Vertriebs- und Abosystem erfolgt gemäß den Regeln und der technischen Spezifikation der Anlage 3 (Kapitel 3).

5.4 Kontrolle

Externe Mandanten mit dem Aufgabenbereich Kontrolle gewährleisten die Erfüllung der Leistungen im Rahmen des vHGS gemäß Kapitel 4.4 Aufgabenbereich Kontrolle (für interne Mandanten).

6 Online-Kundenportal meinRMV

Auf www.rmv.de können Kunden nach einer Anmeldung im Kundenportal meinRMV ein Benutzerkonto eröffnen. Ein zentrales Angebot bei meinRMV ist der internetba- sierte Vertrieb von RMV-Fahrkarten. Das vHGS ist über eine Schnittstelle mit mein- RMV verbunden. Nach erfolgter Anmeldung in meinRMV sind über den RMV-TicketS- hop Wochen-, Monats- und Jahreskarten (Abo und Einmalkauf) erhältlich (vgl. Kapitel 4.1.1 Kundenbedienter Service (Online über meinRMV)).

Darüber hinaus werden vom RMV eigenverantwortlich zusätzliche Kundenservices im Rahmen der Registrierung des Endkunden im Kundenportal meinRMV angeboten, in dessen Zuge auf Nutzungsdaten aus dem vHGS zugegriffen wird.

Bspw. durch Anmeldung und Nutzung von meinRMV-Diensten, u. a.

 RMV-TicketShop und Chipkarte eTicket RheinMain verwalten (ausgenommen ist der Aufgabenbereich Vertrieb JobTicket) Nach Registrierung der Chipkarte in meinRMV können registrierte meinRMV-Kun- den ihre auf der Chipkarte gespeicherten Fahrtberechtigungen sowie dazugehö- rige Rechnungen in meinRMV einsehen. Der Datenzugriff von meinRMV auf das vHGS wird durch die Chipkartenregistrierung des meinRMV-Kunden ermöglicht.  RMV-Smiles (ausgenommen ist der Aufgabenbereich Vertrieb JobTicket) Der RMV betreibt ein online und mobil nutzbares Bonusprogramm mit der Bezeich- nung „RMVsmiles – Das Bonusprogramm“ (nachfolgend: RMVsmiles). Registrierte RMV-Kunden, welche ihre Fahrkarten über den Dienst RMV-TicketShop unter meinRMV (www.rmv.de) erwerben, sammeln nach entsprechender Anmeldung für das Bonusprogramm Bonuspunkte (Smiles), mit welchen sie Rabatt-Gutscheine verschiedener Anbieter erwerben können. Während des Bestellvorgangs einer Fahrkarte im TicketShop werden dem Nutzer noch im Warenkorb die Smiles in Bezug auf den Warenwert-Betrags angezeigt. Der Warenwert-Betrag wird zusam- men mit der Kunden-ID und der Information der Bonusteilnahme des Kunden an das vHGS gesendet. Nach erfolgreicher Abbuchung des Warenwert-Betrags sen- det das vHGS eine entsprechende Information (Abbuchung ist erfolgt) samt Kun- den-ID an den Smiles-Berechner zurück. Die Kunden-ID und erworbene Punkte werden in der Smiles-Datenbank gespeichert.

21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 14 von 19

[Seite 26]

 RMV-10-Minuten-Garantie Im Zuge der Erstattungsanmeldung wird zukünftig auf die vHGS-Fahrkartendaten des registrierten meinRMV-Kunden zugegriffen werden, um eine automatisierte Fahrkartenprüfung durchführen zu können. Voraussetzung ist, neben der Anmel- dung zum Dienst „RMV-10-Minuten-Garantie“, die Chipkartenregistrierung.

Soweit datenschutzrechtlich zulässig, unternimmt der RMV die Bewerbung von Pro- dukten und Marketingaktionen, u. a. durch

 Customer Relationship Management (CRM)- und E-Mail-Marketing Werblicher E-Mailkontakt zu registrierten meinRMV-Kunden, die ebenfalls für den Dienst RMV-TicketShop (sowie ggf. weiteren meinRMV-Diensten) angemeldet sind. Zugriff auf die dienstspezifischen Vertrags- und Nutzungsdaten der Endkun- den, z. B. die erworbenen Fahrkartenarten, den Zeitpunkt der Käufe, die Einlösung eines Rabatt-Coupons sowie gegebenenfalls der Nutzung des Bonusprogramms RMVsmiles, zum Versand von personalisierten Informations-Mailings. Dies kön- nen beispielsweise sein: Informationen über Streckensperrungen auf der Stamm- strecke des Kunden, Informationen zum RMV-TicketShop, der RMV-10-Minuten- Garantie sowie weiterer zukünftig angebotener Services, Geburtstagsmailings als auch Mailings zur Reaktivierung oder Incentivierung (bspw. durch Rabatt-Cou- pons) von Bestandskunden. Der Inhalt von Informations-Mailings hängt von den genutzten Diensten des meinRMV-Kunden ab. Der Versand von Informations-Mai- lings bedarf der ausdrücklichen Einwilligung des Kunden.

7 Gemeinsame Kundenstammdatenbank (RMV-Kundenstammdaten- bank) – voraussichtlich ab Herbst 2021 produktiv

7.1 Einleitung

Zur Erhöhung des Kundenservices sieht der RMV die Einrichtung einer RMV-Kunden- stammdatenbank (KDB) vor, in der sämtliche dienstübergreifenden Kundenstammda- ten des RMV geführt werden sollen, um eine redundanzfreie Datenhaltung zu schaf- fen. Ziel ist die Identifikation des eindeutigen Kunden. In der Gemeinsamen Kunden- stammdatenbank sollen die Kundenstammdaten, die derzeit getrennt in den jeweiligen Verkaufs- oder Servicesystemen (im folgenden auch „Dienst“ genannt) erfasst werden und dadurch zum Teil für ein und denselben Kunden voneinander abweichende Kun- denstammdaten vorliegen können, zentralisiert gespeichert werden. Folgende Perso- nenstammdaten sollen in der KDB gespeichert werden: Name, Vorname, Geschlecht, Titel, Geburtsdatum, Adresse (Straße, Hausnummer, Postleitzahl, Ort), E-Mail-Ad- resse.

Hierzu sollen Kundenstammdaten aus dem meinRMV-Kundenportal, die aktuell und zukünftig durch die Kunden eingegeben werden, sowie Kundenstammdaten, die mit- arbeiterbedient in den verschiedenen personalisierten Diensten erhoben werden:

 eTicket RheinMain (vHGS)  RMV-HandyTicket und RMVsmart (KMS)  meinRMV o RMV-TicketShop 21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 15 von 19

[Seite 27]

o RMVsmiles o HAFAS o RMVmobil o CRM (Microsoft Dynamics 365)

aus den jeweiligen Systemen extrahiert werden und in eine Gemeinsame Kunden- stammdatenbank überführt werden. Es soll ausschließlich eine technische Änderung, im Sinne einer effizienteren Datenhaltung der Kundenstammdaten durchgeführt wer- den. An den in dieser Anlage beschriebenen Aufgaben und Leistungen für die Teilneh- mer und eingesetzte VDL soll sich nichts ändern.

Die Dienste eTicket RheinMain (vHGS) und RMV-HandyTicket werden von der Cubic Transportation Systems (Deutschland) GmbH bereitgestellt. In diesen Diensten exis- tiert jeweils eine eigene Kundendatenbank (parallel zur meinRMV-Kundendatenbank). Die übrigen Dienste nutzen die meinRMV-Kundendatenbank, die von der rms GmbH bereitgestellt wird.

Alle bestehenden Dienste sollen über die aktuell produktive oder eine erweiterte Schnittstelle auf die neue autarke RMV-Kundenstammdatenbank zugreifen. Die RMV- Kundenstammdatenbank soll so konzipiert werden, dass eine beliebige Anzahl weite- rer Dienste (Clients) angeschlossen werden können.

Die dienstübergreifende Datenverwaltung soll so organisiert werden, dass Änderun- gen von Kundenstammdaten in einem Dienst – die entweder in der Regel durch den Kunden selbst oder im Falle des vHGS mitarbeiterseitig initiiert werden – automatisch den anderen Diensten zur Verfügung stehen und diese über die Änderungen informiert werden. Änderungen von Stammdaten, z. B. der Wohnanschrift, Telefonnummer oder E-Mail-Adresse, werden auch auf die anderen Dienste übertragen werden. Damit muss die Änderung nur einmalig vorgenommen werden. Dem Kunden gegenüber muss dies transparent gemacht werden.

 Datenzugehörigkeiten bleiben unverändert: Erfassung der Kundenstammdaten in einer Datenbank, wohingegen dienstspezifische Kundendaten weiterhin in den je- weiligen Systemen (Diensten) gespeichert werden  Zugriff auf einen bestimmten Kundenstammdatensatz nur für Dienste möglich, die von diesem Kunden dazu autorisiert wurden  Zugriff auf Attribute über Rechte des jeweiligen Dienstes geregelt  Zentralisierte dienstübergreifende Datenauskunft (Betroffenenrechte) wird für jene Kunden möglich, die zuvor eine Zustimmung über den dienstübergreifenden Zu- griff auf Ihre Daten gegeben haben

7.2 Systemübersicht

Die zu entwickelnde Kundenstammdatenbank besteht aus drei Systemen.

Das erste System stellt die Datenbank dar. Diese ist für die Speicherung sämtlicher Daten zuständig.

21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 16 von 19

[Seite 28]

Das zweite System stellt die REST-Schnittstelle dar. Diese bietet die im Rahmen die- ses Pflichtenhefts festgelegten Operationen um mit der Datenbank zu interagieren. Jegliche Lese- und Schreibzugriffe finden über diese REST-Schnittstelle statt.

Das dritte System stellt die Backoffice-GUI8 dar. Diese greift ebenfalls über die REST-Schnittstelle auf die Datenbank zu. Über das Backoffice-GUI können Daten in der Datenbank eingesehen, gesucht und bearbeitet werden.

Die REST-Schnittstelle bietet ein Rechtemanagement, wonach folgende Schnittstellen nur auf für sie vorgesehene Operationen zugreifen können  meinRMV  HandyTicket  vHGS  meinRMV  HAFAS  RMVsmiles  CRM (Microsoft Dynamics 365)  Backoffice-GUI

Das Rechtemanagement wird mittels API-Keys realisiert. Über sogenannte scopes werden die Zugriffsrechte auf bestimmte Methoden beschränkt. Sollte ein API-Key ei- nes Drittanbieters kompromittiert werden, so muss dies der Administration mitgeteilt werden, die den alten API-Key invalidiert und einen neuen API-Key erstellt und dem Drittanbieter mitteilt.

Das folgende Diagramm stellt die Systemübersicht der zu entwickelnden Anwendung und der Nutzer dar. Die dunkler markierten Objekte sind dabei die zu entwickelnden Anwendungsbestandteile.

8 Die BackOffice-GUI ist ausschließlich für RMV-interne Zwecke konzipiert, insbesondere für die technische Be- treuung der KDB. Es wird geprüft, in welchem Umfang die Kundenkommunikation Zugriff erhält. 21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 17 von 19

[Seite 29]

Datenbank-Server Linux x64 PostgreSQL x64

HandyTicket CRM

REST-Schnittstellen-Server Linux x64 RMVsmiles vHGS OpenJDK x64 WildFly

HAFAS meinRMV

Backoffice-GUI-Server Linux x64 OpenJDK x64 WildFly

Mitarbeiter Arbeitsplatz 1 mit Mitarbeiter Arbeitsplatz N mit Webbrowser – Backoffice-GUI Webbrowser – Backoffice-GUI

Abbildung 1 – Systemübersicht

7.3 Akteure

Alle Anwendungsfälle werden mit bestimmten Akteuren verbunden. Die Akteure wer- den in der KDB in ein softwareseitiges Rollensystem überführt.

Bei Diensten werden hierbei allerdings nur allgemeine Rollen vergeben. Jeder Dienst muss anschließend für ein eigenes Rechtemanagement sorgen, sodass nur berech- tigte Mitarbeiter auf entsprechende Daten und Funktionen Zugriff haben.

21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 18 von 19

[Seite 30]

9 „Dritte Dienste“ sind die an die KDB angeschlossenen Systeme, z.B. das vHGS. Gegenüber der KDB treten vHGS- Sachbearbeiter mit den Rechten des Dienstes vHGS auf. Intern kann das vHGS ein eigenes differenziertes Rechtemanagement haben. 21-10-01 Anlage 1 zum vHGS-Vertrag Regelwerk vHGS Seite 19 von 19

[Seite 32]

Beschreibung vHGS

Anlage 2 zum vHGS-Vertrag

[Seite 33]

Versionsverwaltung

21-10-01 Anlage 2 zum vHGS-Vertrag Beschreibung vHGS Seite 2 von 14

[Seite 34]

Organisation und Datenverarbeitung im vHGS

1. Zweck des vHGS, Zweck der Verarbeitung

Das verbundweite, mandantenfähige Hintergrundsystem des RMV, kurz vHGS genannt, stellt ein Vertriebssystem für die Ausgabe und Verwaltung von Fahrkarten des öffentlichen Personennahverkehrs dar. Es unterstützt sowohl den direkten Vertrieb am „Point Of Sales“ in großen und kleinen Vertriebstellen als auch die Bearbeitung von Bestellungen und anderen Kundenwünschen in einem Backoffice. Neben der Bearbeitung von Kundenaufträgen, die über Bestellscheine eintreffen, werden auch die notwendigen Prozesse für die Bearbeitung von Aufträgen aus dem RMV-TicketShop bzw. aus dem RMV-Internetkundenportal meinRMV bereitgestellt, sowie für die Bearbeitung von elektronischen Auftragsdateien zu Sammelverträgen mit allgemeinen Großkunden, Nutzern des Firmenkundenrabats, Schulwegkostenträgern und JobTicket- Unternehmen.

Der RMV hat 2012 mit dem eTicket RheinMain die Ausgabe von Zeitkarten auf Chipkarten begonnen. Das eTicket RheinMain ist der Name für ein Verfahren, dass sich zur Ausgabe von RMV-Fahrkarten des zum Einführungszeitpunkt neuartigen Kernapplikationsstandards des Vereins Deutscher Verkehrsunternehmen (kurz VDV-KA) bedient. Da zum Einführungszeitpunkt kein Vertriebssystem eines RMV- Vertriebspartners in der Lage war, diesen Standard zu unterstützen, hatte sich der RMV dazu entschlossen, ein entsprechendes Vertriebssystem bereitzustellen und seinen Vertriebspartnern optional die Nutzung dieser gemeinsamen Vertriebsplattform anzubieten. Eine Ertüchtigung jedes einzelnen Vertriebssystems im Verbund konnte damit vermieden werden und darüber hinaus die Möglichkeit geschaffen werden, dass die beteiligten Vertriebspartner sich direkt gegenseitig vertrieblich im sog. „Service durch Dritte“ unterstützen können. Nur 3 von 41 Verkehrsunternehmen mit Vertriebsstellen im RMV betreiben eigene KA-fähige Vertriebssysteme.

Im Sinne des VDV-KA Standards deckt das vHGS im Hintergrund die klassischen Vertriebsfunktionen sowie den verpflichtenden KA-Datenaustausch von Kundenvertragspartner (KVP), Dienstleistern oder besser den kontrollierenden Verkehrsunternehmen (DL) und dem Produktverantwortlichen (PL) zwischen verschiedenen Akteuren des KA-Rollenmodells ab. Auch bzw. insbesondere, wenn sich einer der Akteure eines eigenen Vertriebssystem bedient.

2. Aufbau und Zugriff auf das vHGS

Die nachfolgende Abbildung zeigt eine Übersicht über den Aufbau und die Organisation des vHGS in Bezug auf den Zugang zum System:

21-10-01 Anlage 2 zum vHGS-Vertrag Beschreibung vHGS Seite 3 von 14

[Seite 35]

Das vHGS wird zentral in einem Rechenzentrum (vHGS-RZ) betrieben und ist als Webanwendung für unterschiedliche Nutzergruppen erreichbar:

 Gemeinsame Kundenstammdatenbank: In der Gemeinsamen Kundenstammdatenbank (KDB) sollen die Kundenstammdaten, die derzeit getrennt in den jeweiligen Verkaufs- oder Servicesystemen erfasst werden (bspw. in der vHGS-Datenbank) und dadurch zum Teil für ein und denselben Kunden voneinander abweichende Kundenstammdaten vorliegen können, zentralisiert gespeichert werden. Folgende Personenstammdaten sollen in der Gem. KDB gespeichert werden: Name, Vorname, Geschlecht, Titel, Geburtsdatum, Adresse (Straße, Hausnummer, Postleitzahl, Ort), E-Mail-Adresse.

 vHGS-Datenbank: Die vHGS-Datenbank speichert alle dienstspezifischen Kundenstammdatendaten, wie Vertragsstammdaten und Nutzungsdaten.

 Die vHGS-Anwender sind Mitarbeiter der Verkehrsunternehmen oder von diesen beauftragte Dienstleister, die in einer Vertriebsstelle oder in einem Backoffice Fahrkarten ausstellen, Kundenwünsche bearbeiten oder sonstige Aufgaben der Vertragsverwaltung erledigen.

 Die vHGS-Report-Anwender sind Mitarbeiter der Verkehrsunternehmen oder von diesen beauftragte Dienstleister, die die spezifischen Schnittstellen für die Übernahme der Buchungs- und Vertriebsdaten in die Finanzbuchhaltung ihrer Unternehmen erzeugen oder zur Meldung der Verkaufsdaten an ihre LNO bzw. den RMV. Andere Reports werden für vertriebliche Zwecke, wie die Provisionierung von Vertriebsstellen, erzeugt oder zur Bereitstellung von Managementinformationen bzw. Statistiken.

 Externe Systeme sind Terminalmanagementsysteme von Busdruckern, Kontrollgeräten und Automaten oder auch das RMV-Kundenportal meinRMV mit dem RMV-TicketShop. Darüber hinaus gehören aber auch KA-konforme Vertriebssysteme von Verkehrsunternehmen, die sich nicht des vHGS bedienen,

21-10-01 Anlage 2 zum vHGS-Vertrag Beschreibung vHGS Seite 4 von 14

[Seite 36]

jedoch über eine bidirektionale Schnittstelle (BIDI – Bidi I und/oder Bidi II) mit dem vHGS verbunden sind, dazu. Im Weiteren auch die Systeme der RMV- Bezahlplattform, des Massenpersonalisierers, von Informationsdiensten oder Inkassounternehmen.

 Die Mitarbeiter des Systemherstellers und –betreibers Cubic haben darüber hinaus einen VPN-Zugang, der nicht nur die Nutzung der Applikation, sondern auch einen direkten Zugriff auf die Datenbank des vHGS zum Zwecke der Betriebsführung ermöglicht.

Das vHGS wurde unter Berücksichtigung der Rechte und Freiheiten der von der Verarbeitung betroffenen natürlichen Personen entwickelt. Es gewährleistet im Rahmen der konkreten Auftragsverarbeitung ein dem Risiko angemessenes Schutzniveau hinsichtlich der Vertraulichkeit, der Integrität, der Verfügbarkeit sowie der Belastbarkeit durch die nachstehend aufgeführten Datenverarbeitungsprozesse und –maßnahmen. Die Entwicklung aller wesentlichen Teile des vHGS (u.a. Datenbankmodell, Prozesse, …) wurde zu Beginn umfassend durch den hessischen Datenschutzbeauftragten begleitet.

Die Zugriffsrechte werden im vHGS wie folgt organisiert: Jeder Mandant im vHGS benennt einen Mitarbeiter als internen vHGS-Administrator. Dieser erhält von der technischen Betriebsführung des vHGS Zugangsdaten, die auf die Daten des entsprechenden Kundenvertragspartners bzw. der entsprechenden Kontrollorganisation beschränkt sind. Alle weiteren Mitarbeiter des Mandanten erhalten ihre Zugangsdaten von diesem internen Administrator. Dabei kann der Administrator maximal die eigenen Rechte vererben.

3. Datenerhebung, Datenbearbeitung

Die Bearbeitung von personenbezogenen Daten im vHGS berücksichtigt in jeder Phase die Grundsätze des Art. 5 DS-GVO. Hierzu gehören insbesondere  die Zweckbindung der Daten,  die Datenminimierung,  die Speicherbegrenzung sowie  die Integrität und Vertraulichkeit.

a) Mandantenspezifische Trennung der Daten in der gemeinsamen vHGS Datenbank

Alle Daten, die durch die Mandanten als Kundenvertragspartner oder Kontrollorganisation bzw. durch den Kunden selbstbedient über meinRMV in das vHGS eingegeben werden, werden in einer gemeinsamen Datenbank (ein Datenbankmanagementsystem) mit einem einheitlichen Datenmodel abgelegt. Die mandantenspezifische Trennung der Daten (logische Datentrennung), die den Zugriff eines Mandanten in der Applikation eindeutig beschränkt, erfolgt entsprechend dem jeweiligen funktionalen Kontext über die folgenden Objekte:

 Chipkarte: Kundenvertragspartner können auf die Daten zugreifen, die mit der von ihnen ausgegebenen Chipkarte (über KA-Applikations-ID) verknüpft sind.

 Fahrkarte: Kundenvertragspartner können auf die Daten zugreifen, die mit den von ihnen verkauften Fahrkarten (über Berechtigungs-IDs) verknüpft sind.

 Vertrag (Einzel- oder Sammelvertrag): Kundenvertragspartner können auf die Daten zugreifen, die mit den von ihnen abgeschlossenen Einzel- oder Sammelverträge (über Name, Kunden-/Vertragsnummern) verknüpft sind.

21-10-01 Anlage 2 zum vHGS-Vertrag Beschreibung vHGS Seite 5 von 14

[Seite 37]

 Kontrollterminal: Kontrollorganisationen können auf die Daten zugreifen, die sie über die TerminalManagementSchnittstelle (TMS) vom Hintergrundsystem ihrer Kontrollterminals an das vHGS geliefert haben (Verknüpfung über Geräte-ID).

Zur Optimierung des Kundenservice wurden Ausnahmen von der mandantenspezifischen Trennung der Daten in Einzelfällen möglich gemacht. Den sogenannten „Service durch Dritte“ kann ein Kunde in allen Vertriebsstellen des RMV in Anspruch nehmen und sich somit ggf. den Gang zu seinem Kundenvertragspartner ersparen. Voraussetzung für den Zugriff auf Daten, die über die logische Grenze des jeweiligen Mandanten hinausgehen, bedarf der Zustimmung des Kunden im jeweiligen Einzelfall. Der jeweilige Vertriebsmitarbeiter erhält immer einen Hinweis in Form eines PopUps, bevor er den „Service durch Dritte“ beginnt. Er kann nur weiterarbeiten, wenn er diesen Hinweis aktiv bestätigt. Diese Bestätigung durch den Mitarbeiter wird protokolliert. Für externe Mandaten (RMV-Vertriebspartner mit eigenem KA-Vertriebssystem) werden die Informationen, die im Rahmen des “Service durch Dritte“ zur Verfügung gestellt werden, über eine entsprechende Schnittstelle (BIDI „Verkauf & Service“) zur Verfügung gestellt.

Ausnahme/Anwendungsfall Nr. 1: „Kundensuche“

Kundendaten werden im vHGS nach Möglichkeit nicht redundant angelegt (Datensparsamkeit); Weder, wenn sie mehrere Geschäftsbeziehungen mit einem Mandanten haben, noch, wenn sie diese mit unterschiedlichen Mandanten im vHGS haben. D.h. bspw., dass ein Mitarbeiter bei der Vertragsanlage innerhalb der ganzen, gemeinsamen vHGS-Kundendatenbank suchen und einen eventuell bereits vorhandenen Kundendatensatz mit dem eigenen Geschäftsvorfall verknüpfen kann.

Um Missbrauch vorzubeugen, wurde mit den Vertretern des hessischen Datenschutzbeauftragten abgestimmt, dass in der Kundensuche mindestens der erste Buchstabe des Vornamens und die ersten 6 Buchstabens des Nachnamens bzw. der gesamte Nachname als Suchkriterium vorgegeben werden müssen.

Ausnahme/Anwendungsfall Nr. 2 „Service durch Dritte“

Kunden sollen die Möglichkeit erhalten, sich für bestimmte Servicefälle an alle Vertriebsstellen im gesamten RMV-Gebiet wenden zu können, und nicht nur an Vertriebsstellen ihres jeweiligen Vertragspartners. Im Zentrum stehen dabei der Ersatz einer Chipkarte mit allen dazugehörigen Fahrkarten und der Erhalt von Kundeninformationen bezüglich nachfolgender Fragestellungen:

 Was steht auf der Chipkarte bzw. welche Fahrkarten sind darauf gespeichert?

 An wen muss der Kunde sich wenden, wenn er ein Anliegen hat, dass nicht durch einen „fremden“ Vertriebspartner im Rahmen des Service durch Dritte bearbeitet werden kann?

b) Erhebung Kundenstammdaten und Vertragsdaten

Die Erfassung der Daten ist für die Abwicklung der Vertragsbeziehung unabdingbar. Daten werden nach dem Prinzip der Datensparsamkeit/Datenminimierung erhoben (Kundenstammdaten werden nur einmalig erhoben und nicht – wie bis vor einiger Zeit – mehrfach in verschiedenen Vertriebssystemen gespeichert.)

Die Erfassung von Daten eines Kunden erfolgt

21-10-01 Anlage 2 zum vHGS-Vertrag Beschreibung vHGS Seite 6 von 14

[Seite 38]

 auf Grundlage eines ausgefüllten und unterschriebenen Bestellscheins eines Kunden oder eines entsprechenden Kundenschreibens (u. a. in einer Vertriebsstelle oder im Backoffice),

 auf Grundlage seiner eigenen Angaben, die er über meinRMV online eingegeben hat oder

 auf Grundlage einer Bestelldatei eines Großkunden (z.B. Schulwegkostenträger).

Kunden, die keinen Vertrag abschließen bzw. ihre persönlichen Daten nicht Preis geben möchten, können im RMV alternativ anonym Fahrkarten auf Chipkarten erwerben.

c) Erhebung von Mitarbeiterstammdaten bzw. Mitarbeiterstammdaten von Subunternehmern

Mitarbeiterstammdaten werden vom jeweiligen Administrator des Mandanten für alle Mitarbeiter, die mit dem vHGS arbeiten, erfasst. Darüber hinaus bekommt der Mitarbeiter einen Benutzernamen und ein Passwort, welches der Mitarbeiter beim ersten Anmelden ändern kann bzw. ändern muss (sofern der Mandant dies so im vHGS selbst einrichtet). Der Administrator kann dann zwar weiterhin das Benutzerkonto des Mitarbeiters einsehen, jedoch kann sich nur der jeweilige Mitarbeiter an einem Terminal anmelden (da nur er das neue Passwort kennt).

Mit der Eingabe eines Mitarbeiters werden die für ihn vorgesehenen Rechte durch den Administrator konfiguriert.

Die Erfassung der Mitarbeiterdaten ist notwendig,

 um den Bearbeiter von Vorgängen im vHGS zu dokumentieren sowie  um Parameter abzuspeichern (z. B. Telefonnummer), die in Kundenbelegen automatisiert eingetragen werden.

d) Erhebung von personenbezogenen Daten von privaten Vertriebspartnern

Zum Zwecke der Auszahlung von Provisionen wird eine zur Vertriebsstelle gehörige Bankverbindung sowie Steuernummer + USt-ID-Nummer erfasst.

e) Erhebung Transaktionsnachweise (Nachweise zur Kontrolle, Ausgabe, Rücknahme, Sperrung und Entsperrung)

Rechtsgrundlage ist auch hier Artikel 6 Abs. 1 Buchstabe b) DSGVO.

Die Erfassung ist für die Funktionalität des eTicket RheinMain

 zur Manipulation- und Missbrauchsanalyse,  zur frühzeitigen Erkennung von ggf. vorhandenen Fehlern im System (z. B. wird die hier erkannt, wenn Terminals zeitweise keine Sperr- und Aktionslisten abrufen) und  zur Sicherung der Datenqualität (z. B. Erkennen, ob der aktuelle Tarif geladen ist)

zwingend notwendig.

Die Daten werden von den jeweiligen Kontroll- bzw. Vertriebsterminals an ihr jeweiliges Terminal-Hintergrundsystem übermittelt (WLAN, Mobilfunk oder im Einzelfall über einen

21-10-01 Anlage 2 zum vHGS-Vertrag Beschreibung vHGS Seite 7 von 14

[Seite 39]

externen Datenspeicher) und von dort an das vHGS geliefert (über gesicherte Web- Schnittstelle, teilweise zusätzlich via VPN-Tunnel).

f) Protokollierung Datenzugriff Protokollierung der Zugriffe auf die Daten ist Teil des Datensicherungskonzeptes und trägt zur Wahrung der Integrität und Vertraulichkeit der Daten bei.

Protokolliert wird lediglich der vHGS User-Name und nicht der Klarname des zugreifenden Mitarbeiters. Eine Zuordnung des User-Namen zum Klarnamen ist lediglich dem Administrator bzw. dem Mitarbeiter selbst möglich.

4. Datenübermittlung an externe Systeme/Empfänger

a) Massenpersonalisierer (MP) Aufgabe des Massenpersonalisierers ist es, für die Mandanten – auf Auftrag hin – Chipkarten für deren Kunden mit den entsprechenden Fahrberechtigungen zu „beschreiben“. Darüber hinaus erfolgt dann auch der Versand der Chipkarten zusammen mit einem Anschreiben an die Kunden.

Der Austausch der dafür relevanten Daten zwischen MP und vHGS erfolgt über eine entsprechende Schnittstelle.

Kategorien von Daten, die verarbeitet werden  Benutzerverwaltungsdaten: Mitarbeiter von der verantwortlichen Stelle, Benutzeridentifikation  Endkundenstammdaten: Name, Vorname, Geschlecht, Titel, Geburtsdatum, Adresse (Straße, Hausnummer, Postleitzahl, Ort), E-Mail-Adresse, Bankverbindung (IBAN, BIC, Name des Bankinstituts), Kundennummer, Vertragsnummer, Chipkartennummer, zugeordnete Rolle (Besteller, Bezahler, Benutzer der Fahrkarte).  Endkundennutzungsdaten: Berechtigungs-ID, Tarifprodukt (Fahrkartenart), Vertragspartner (leistungserbringendes Verkehrsunternehmen), Verkaufsdatum, Verkaufsuhrzeit, Start und Ziel Tarifgebiet, Beginn und Ende Gültigkeit, Preis

b) Bonitätsauskunft Im Rahmen der Bestellbearbeitung können auf gesonderte Anfrage die personenbezogenen Daten Name, Geburtsdatum, Anschrift des Bestellers sowie die Daten zur Bankverbindung an eine festgelegte Auskunftei übermittelt zwecks Erhalts einer Bonitätsaussage. Das Ergebnis der Bonitätsprüfung wird in Form einer Ampel angezeigt. Zudem besteht die Möglichkeit, sich darüber hinaus die konkreten Negativ-Merkmale anzeigen zu lassen.

Da ggf. jede einzelne Abfrage beim Auskunftsdienst kostenpflichtig ist, speichert das vHGS die Abfrageergebnisse. Wurde für einen Kunden bereits eine Auskunft eingeholt, wird nach Klicken auf den Button „Abfragen“ zunächst das Ergebnis dieser Abfrage angezeigt. Zu erkennen ist dies am Abfragedatum, das ggf. in der Vergangenheit liegt. Soll die Abfrage aktualisiert werden, also eine Bonitätsprüfung zum aktuellen n Datum durchgeführt werden, muss der Mitarbeiter auf „Abfrage aktualisieren“ klicken. Es wird dann eine weitere ggf. kostenpflichtige Auskunft für diesen Kunden eingeholt.

c) Geldinstitute, Kreditkartenunternehmen, Inkassounternehmen Über die RMV-Bezahlplattform werden Zahlungen abgewickelt, die durch den Verkauf von RMV-Tickets für den öffentlichen Nahverkehr im Gebiet des RMV abzurechnen sind. Im Rahmen der Abrechnung werden die dafür erforderlichen personenbezogenen Daten

21-10-01 Anlage 2 zum vHGS-Vertrag Beschreibung vHGS Seite 8 von 14

[Seite 40]

an Geldinstitute, Kreditkartenunternehmen und Inkassounternehmen übermittelt. Ziel ist die Realisierung des mit dem Kunden vertraglich vereinbarten Geldeinzugs über Geldinstitute oder Kreditkartenunternehmen bzw. die Übergabe aller für ein gerichtliches Mahnverfahren notwendigen Daten an ein Inkassounternehmen. Der Datenaustausch mit Hausbanken erfolgt über das EBICS-Verfahren.

Kategorien von Daten, die verarbeitet werden  Benutzerverwaltungsdaten: Mitarbeiter von der verantwortlichen Stelle, Benutzeridentifikation, Benutzerstammdaten in Übereinstimmung mit der Hauptverwaltung, Benutzerverwaltung der Anwendung  Endkundenstammdaten: Kontoinhaber (Vorname und Nachname), Kontodaten, Bank- oder Kreditkarteninformationen (Kreditkarteninhaber, Kreditkartenunternehmen (Visa/MasterCard) und Pseudokreditkartennummer [ReferenzID]), SEPA-Mandat  Endkundennutzungsdaten: Kontoauszugsdaten des Verkehrsunternehmens, SEPA-Lastschriftinformationen, Buchungsdaten und Zahlungsinformationen Reporting, Transaktionsstatistik

5. Löschen von Daten, Löschfristen

Grundsätzlich gilt für alle gespeicherten Daten das Prinzip der Datensparsamkeit. Das bedeutet zum einen, dass nur die Daten erhoben werden dürfen, die unbedingt für die Ausführung des Dienstes notwendig sind. Zum anderen heißt das aber auch, dass die Daten nur so lange wie nötig im System vorgehalten werden dürfen. Alle vom vHGS gespeicherten Daten werden einer Kategorie zugeordnet. Die folgende Tabelle führt die Kategorien auf, erläutert, warum sie erhoben werden, und spezifiziert, wie und wann sie wieder entfernt werden.

21-10-01 Anlage 2 zum vHGS-Vertrag Beschreibung vHGS Seite 9 von 14

[Seite 41]

Hinweis zu Daten der Nutzer von JobTickets

Die Nutzer der JobTickets sind Mitarbeiter von Unternehmen, die einen JobTicket-Vertrag abgeschlossen haben. Für die Löschung der Daten gelten die unter KUNDE angegebenen Regelungen. Die Daten der Nutzer werden jedoch gemäß den folgenden Regelungen frühzeitig maskiert.

Die Maskierung erfolgt in der Form, dass alle Felder des Nutzerdatensatzes auf null gesetzt werden bzw. wo dies technisch nicht möglich ist auf „*“. Die Personalnummer wird vom System mit einer neuen eindeutigen Personalnummer (Dummy) überschrieben. Zwischen alter (echter) Personalnummer und der neu erzeugten Personalnummer besteht kein Zusammenhang.

Die Maskierung erfolgt zu folgenden Zeitpunkten

 Wird ein JobTicket Einzelvertrag gekündigt (Status „Mitarbeiter scheidet aus Unternehmen aus“), so werden die personenbezogenen Daten 24 Stunden nach dem letzten Gültigkeitstag des JobTickets im vHGS maskiert.  Wenn ein JobTicket Einzelvertrag temporär deaktiviert wird und der Mitarbeiter den Status „Mitarbeiter hat keinen Bedarf“ erhält, werden die Daten nach 365 Tagen maskiert.  Wenn ein JobTicket Einzelvertrag temporär deaktiviert wird und der Mitarbeiter den Status „ruhend“ erhält, werden die Daten nach 90 Tagen maskiert.

Hinweis zu Daten aus der Kontrolle von eTickets

In den bei der Kontrolle von eTickets entstehenden KA-Transaktionsnachweisen vom Typ TXEBER (059) werden bei Eingang im vHGS folgende Felder des Datenbereichs „AllgemeineFahrttransaktionsdaten“ mit „0“ (oder anderslautenden nichtinformationstragenden Werten) überschrieben:  fahrtNummer  berLogLinieVarianteID.linieID 21-10-01 Anlage 2 zum vHGS-Vertrag Beschreibung vHGS Seite 10 von 14

[Seite 42]

 berLogLinieVarianteID.varianteNummer

6. Allgemeine im vHGS enthaltene technische und organisatorische Maßnahmen gem. Art. 32 DS-GVO

Zugangskontrolle Die Anmeldung zum vHGS ist nur mit Benutzer ID und Kennwort möglich. Nach mehreren fehlgeschlagenen Anmeldeversuchen wird der Zugriff gesperrt. Die Passwörter werden als Hash-Werte abgelegt und können auch von Administratoren nicht ausgelesen werden.

Zugriffskontrolle Die Zugriffskontrolle erfolgt durch ein Benutzer- und Rollenkonzept: Nur nach Anmeldung mit Benutzername und Kennwort kann ein Zugriff auf die Daten erfolgen. Aktionen sind nur gemäß der jeweils individuellen Berechtigung des Benutzers möglich. Die Anzahl der Benutzer wird so klein wie möglich gehalten.

Weitergabekontrolle Unbefugtes Lesen, Kopieren, Verändern oder Entfernen von personenbezogenen Daten wird durch Verschlüsselung und weitere Sicherheitsmaßnahmen entsprechend dem Stand der Technik verhindert. Die Schnittstellen des Systems sind klar definiert und entsprechend dem Stand der Technik gesichert.

Eingabekontrolle Alle Änderungen und Weitergaben von Daten werden im System dokumentiert.

Auftragskontrolle Die im Rahmen des vHGS von Dienstleistern übernommene Auftragsverarbeitung erfolgt ausschließlich auf Grundlage der DS-GVO sowie der jeweils mit dem Verantwortlichen getroffenen Vereinbarung zur Auftragsverarbeitung.

Verfügbarkeitskontrolle Die personenbezogenen Daten sind mehrfach vor Verlust und Zerstörung gesichert. Zu den Sicherungsmaßnahmen gehören u.a. redundante Datenhaltung sowie eine regelmäßige Datensicherung.

Verpflichtung auf den Datenschutz Alle Mitarbeiter werden während ihrer Tätigkeit mit dem vHGS und darüber hinaus zur Vertraulichkeit sowie auf die Einhaltung der Datenschutzrichtlinien hingewiesen und verpflichtet.

7. Wahrung der Rechte der Betroffenen

a) Erteilung von Auskünften und Einsichtnahme (gem. Art 15 DS-GVO)

Ein Betroffener kann sich bei seinem bzw. einem seiner Kundenvertragspartner (KVP) eine Auskunft über die von ihm im vHGS gespeicherten personenbezogenen Daten geben lassen. Diese Information beinhaltet ggf. auch KVP-übergreifend alle personenbezogenen, im vHGS gespeicherten Daten des Betroffenen. Zur Vermeidung von Missbrauch wird diese Auskunft niemals direkt erteilt, sondern kann ausschließlich über den jeweiligen Datenschutzbeauftragten eines KVP beantragt werden. Die Beantragung dieser Auskunft kann wie folgt erfolgen:  Schriftlich, 21-10-01 Anlage 2 zum vHGS-Vertrag Beschreibung vHGS Seite 11 von 14

[Seite 43]

 Per E-Mail an den jeweiligen Datenschutzbeauftragten des KVP,  Persönlich in einer Vertriebsstelle (wobei die Vertriebsstelle verpflichtet ist, eine Identitätsprüfung durchzuführen und den Antrag erst dann an den entsprechenden Datenschutzbeauftragten weiterzuleiten). Die Antwort erfolgt in den beiden ersten Fällen ausschließlich an die im vHGS gespeicherte Adresse bzw. E-Mail Adresse des Betroffenen, um sicher zu stellen, dass nicht ggf. ein Unberechtigter sich eine Auskunft über einen Dritten geben lässt.

Die Auskunft wird ab eindeutiger Identifizierung des Betroffenen innerhalb von spätestens 4 Wochen schriftlich oder digital per E-Mail, gegebenenfalls über einen gesicherten Datenraum mit Passwortvergabe, erteilt. Bei Übermittlung per E-Mail sollte eine PKI-Verschlüsselung angewendet werden. Stand der Technik sind hier S/MIME oder OPEN PGP. Alternativ können versendete Dateien auch mit einem Passwort geschützt werden.

Mögliche Abweichungen von den hier getroffenen Regelungen sind § 5 der Joint Controllership-Vereinbarung zu entnehmen und zu befolgen.

b) Benachrichtigungen

Daten werden ausschließlich mit Zustimmung der Betroffenen erhoben, daher entfallen Benachrichtigungen.

c) Datenberichtigung, –löschung gem. Art. 16 + 17 DS-GVO

Die Kundendaten können jederzeit auf Wunsch des Kunden korrigiert oder gelöscht werden, sofern weder gesetzliche Regelungen noch berechtigte Interessen des Verantwortlichen dagegen stehen. Der Kunde bekommt nach der Änderung einen Beleg über die Änderung ausgehändigt.

d) Recht auf Datenübertragbarkeit gem. Art. 20 DSGVO Nicht relevant, da keine Möglichkeit zur Vertragsübernahme durch einen anderen Anbieter gegeben ist.

8. Risiko durch Datenmissbrauch

a) Verlust der Vertraulichkeit Durch Abhören der Kommunikation: Daten, die während der Kommunikation mit dem System verschickt werden, werden von unberechtigten Personen mitgelesen.

Durch Auslesen der Datenbankinhalte: Innerhalb des Systems gespeicherte Daten werden von unberechtigten Personen ausgelesen. Systemadministratoren ist dies prinzipiell möglich. Nutzer können nur Daten in definierten Anwendungsfällen auslesen. Außenstehenden ist kein direkter Zugriff auf die Datenbankinhalte möglich.

Schutzmaßnahmen: Die Kommunikation mit dem Webfrontend erfolgt über das https-Protokoll. Die Kommunikation zwischen Terminalgeräten und Hintergrundsystem erfolgt ebenfalls über das https-Protokoll. Firewalls etc. verhindern das Auslesen der Datenbank von außen. Die Administratoren werden auf das Datenschutzgesetz verpflichtet. Das Benutzerrollenkonzept regelt die Sicht auf personenbezogene Daten. Die Anmeldung im System ist nur mit Benutzer-ID und Kennwort möglich. Nach mehreren fehlgeschlagenen Anmeldeversuchen wird der Zugriff gesperrt.

21-10-01 Anlage 2 zum vHGS-Vertrag Beschreibung vHGS Seite 12 von 14

[Seite 44]

Passwörter werden als Hash-Werte abgelegt und können auch von Administratoren nicht ausgelesen werden. Der Datenaustausch mit Hausbanken erfolgt über das EBICS-Verfahren.

b) Verlust der Integrität Durch Wiedereinspielen alter Transaktionsdaten: Dieser Angriff kann meist nur von den Administratoren des Systems durchgeführt werden, da diese als Einzige Zugriff auf alte Datenbankzustände haben.

Durch Maskerade: Der Angreifer ersetzt einen Kommunikationsteilnehmer und übernimmt dessen Rolle. Dadurch wird nicht nur die Vertraulichkeit verletzt, sondern auch die Zurechenbarkeit der Daten.

Durch Inkonsistenz gespeicherter Daten: Falls die Datenbank nicht in einem konsistenten Zustand gehalten wird, z.B. durch nicht-atomar ausgeführte Transaktionen, können Fehler und Datenverluste die Folge sein.

Durch Veränderung der Kommunikationsdaten: Durch einen Angreifer oder einen Systemfehler werden Manipulationen an den ausgetauschten Daten vorgenommen. Dies kann eine gezielte inhaltliche Änderung der Daten zur Folge haben oder einen Systemabsturz durch nicht interpretierbare Daten.

Schutzmaßnahmen: Inkonsistenzen werden durch ACID-Prinzip verhindert (Transaktionen werden nur vollständig oder gar nicht durchgeführt). Datenaustausch zwischen Terminals und Hintergrundsystem durch eine Ende-zu-Ende- MAC Sicherung gestützt.

c) Verlust der Verfügbarkeit Durch Denial of Service (Sabotage): Durch gezielte Überlastung eines Servers wird versucht, den Dienst oder Teile davon arbeitsunfähig zu machen.

Durch Systemausfall: Bei einem Systemausfall können keine Transaktionen durchgeführt werden. Gründe können ein Angriff auf das System, Konfigurationsfehler oder ein Netzausfall sein.

Durch Verlust gespeicherter Daten: Falls Daten gelöscht oder verändert werden, können zahlreiche Transaktionen nicht mehr korrekt durchgeführt werden (z.B. Anmeldung, Bezahlvorgänge). Gründe für den Verlust können ein Angriff oder Fehler bei der Handhabung der Daten durch die Systemadministratoren sein.

Schutzmaßnahmen: Die Server sind so konfiguriert, dass nur wirklich benötigte Funktionen verfügbar sind. Nicht benötigte Funktionen sind deaktiviert. Maßnahmen zur Redundanz, Monitoring und automatisiertem Wiederanlaufen sind vorgesehen.

21-10-01 Anlage 2 zum vHGS-Vertrag Beschreibung vHGS Seite 13 von 14

[Seite 45]

Folgende Tabelle zeigt exemplarisch mögliche Probleme im Zusammenhang mit den o.g. Risikofaktoren:

21-10-01 Anlage 2 zum vHGS-Vertrag Beschreibung vHGS Seite 14 von 14

[Seite 46]

Konzept Externe Mandanten – Bidirektionale

Schnittstelle

Anlage 3 zum vHGS-Vertrag

[Seite 47]

Die bidirektionale Schnittstelle (Bidi) besteht aus zwei Teilen:

1. KA Datenaustausch (Bidi I: Kontrolle und Verkauf)

2. Vertrieb & Service (Bidi II: Service durch Dritte und Internetvertrieb)

Teil I: KA Datenaustausch (Bidi I: Kontrolle und Verkauf)

Versionsverwaltung

21-10-01 Anlage 3 zum vHGS-Vertrag Konzept Externe Mandanten

[Seite 48]

vHGS eTicket RheinMain Konzept - Externer Mandant

Inhalt

1 Einleitung ........................................................................................................................... 3 2 Aufgabenstellung .............................................................................................................. 3 3 Lösungskonzept ................................................................................................................ 4 3.1 Vorbemerkung: Stellvertreter-AHS und KOSES ........................................................... 4 3.2 Datenflüsse (KA Transaktionsdatensätze) .................................................................... 5 3.2.1 Sperrmanagement – Berechtigungen (RMV-EFS) ................................................. 5 3.2.2 Sperrmanagement – NmApplikation (eTicket RheinMain Nutzermedium) ............. 6 3.2.3 Sperrmanagement – KEY ..................................................................................... 6 3.2.4 Sperrmanagement – SAM, ORG ........................................................................... 7 3.2.5 Aktionsmanagement (RMV-EFS) .......................................................................... 7 3.2.6 Quittungsnachrichten TXA, TXB ............................................................................ 8 3.3 Ergänzende Festlegungen ........................................................................................... 8 3.3.1 TX_BASE, Signatur ............................................................................................... 8 3.3.2 TX_BASE, Adressierung der KA-Nachrichten ....................................................... 8 3.3.3 Sperrlisten ............................................................................................................. 9 3.3.4 Defekte Medien ..................................................................................................... 9 3.3.5 Übermittlung TXSNAWA vom AH-KOSE an den KVP ......................................... 10 3.4 Technische Festlegungen zur Schnittstelle ................................................................ 10 3.5 KA XML-Schema ........................................................................................................ 11 3.6 Sonderfallbehandlung für externe Mandanten im vHGS ............................................. 12 4 Bewertung im Hinblick auf das Sicherheitsmanagement ............................................. 13

1 Einleitung

Die Verkehrsunternehmen VGF und HEAG verwenden für Vertrieb des eTicket RheinMain nicht das vHGS als KVP- bzw. DL-Referenzsystem (logische Referenzsysteme im Standard der VDV Kernapplikation), sondern eigene eTicket Hintergrundsysteme. Im Konzept „Externer Mandant“ werden die in diesem Zusammenhang getroffenen Vereinbarungen für die Verknüpfung mit Prozessen des vHGS dokumentiert. Grundsätzlich ist die Lösung nicht auf die genannten Unternehmen beschränkt. Da eine Ausweitung des Konzeptes aber nicht geplant ist, werden die beiden relevanten Unternehmen konkret benannt.

2 Aufgabenstellung

Es ist geplant, dass diese Hintergrundsysteme im Sommer 2012 über eine bidirektionale Schnittstelle mit dem vHGS verbunden werden, so dass die VGF und HEAG als Teilnehmer der RMV KVP-Agentur in das verbundweite Servicekonzept eingebunden sind. Das technische Konzept dieser bidirektionalen Schnittstelle zur Synchronisation der Daten im vHGS mit denen im jeweiligen VU-HGS wurde im März 2011 zwischen den Beteiligten grob skizziert und soll im Januar 2012 wieder aufgenommen werden. Damit hat das vorliegende Dokument für die Zeit vom Systemstart des eTicket RheinMain zum Fahrplanwechsel 2012 bis zur Herstellung der Betriebsbereitschaft der bidirektionalen Schnittstelle einen temporären Charakter.

Version: 1.3 Datum: 04.10.2011 Datei: 11-12-08 Anlage 6_ExtMandant_Konzept_v1.4_Endversion.docSeite 3 von 13 Cubic Transportation Systems (Deutschland) GmbH, Vertraulich

[Seite 49]

vHGS eTicket RheinMain Konzept - Externer Mandant

Für den oben genannten Übergangszeitraum soll ein eingeschränkter Datenaustausch zwischen dem vHGS und den Hintergrundsystemen (VU-HGS) der VGF und der HEAG hergestellt werden. Der Datenaustausch erfolgt mittels KA Transaktionsdatensätzen (KA Version 1.107). Um die Aufwände für die Implementierung zu begrenzen soll die zum Systemstart verwendete Schnittstelle zwischen vHGS und VU-HGS sich auf die für das Sperrmanagement und das Aktionsmanagement zwingend erforderlichen Daten beschränken. Daten über ausgegebene Nutzermedien und Berechtigungen werden nicht übermittelt. Erst mit dem Betriebsstart der bidirektionalen Schnittstelle werden die seit dem Systemstart angefallenen Daten von den VU-HGS an das vHGS übermittelt. Für die von VGF und HEAG ausgegebenen Nutzermedien (KA Nutzermediumapplikation) und eTickets (KA Berechtigung, RMV EFS) wird es bis zur Herstellung der Betriebsbereitschaft der bidirektionalen Schnittstelle keinen unternehmensübergreifenden Service (Service durch Dritte) geben. Umgekehrt werden auch die von den vHGS-Mandanten ausgegebenen Nutzermedien und eTickets bei der VGF und HEAG keinen Service durch Dritte erhalten. Um nach Herstellung der Betriebsbereitschaft der bidirektionalen Schnittstelle eine schnelle Migration ohne Austausch von Nutzermedien und eTickets zu ermöglichen, sollen VGF und HEAG bereits ab dem Systemstart die KVP-ID der RMV KVP-Agentur verwenden. Sie werden daher in diesem Konzept als Externe Mandanten bezeichnet. Die Verwendung der KVP-ID der RMV KVP-Agentur (und des damit einhergehenden Schlüsselmaterials) wirkt sich auch günstig auf die Einbindung der VGF und der HEAG in das Aktionsmanagement des eTicket RheinMain aus (In einer Lösung mit jeweils eigenen KVP-ID für VGF und HEAG wäre es notwendig, dass die Terminals das Nachladen von Schlüsseln und die Verwendung von „Fremd“-Schlüsseln als ausführender KVP beherrschen – beides wird derzeit von den VU-HGS der VGF und der HEAG nicht unterstützt). Die Verwendung der KVP-ID der RMV KVP-Agentur durch externe Systeme (ohne Datensynchronisation im Sinne der bidirektionalen Schnittstelle) erfordert Softwareanpassungen im vHGS. Der Grund dafür liegt darin, dass alle bisherigen Konzepte zur Steuerung der Datenverarbeitung im vHGS darauf aufbauten, dass die RMV KVP-Agentur von den Mandanten des vHGS gebildet wird.

3 Lösungskonzept

3.1 Vorbemerkung: Stellvertreter-AHS und KOSES

Bei der Gestaltung der Schnittstelle ist folgender, allgemein für das vHGS geltender Sachverhalt zu berücksichtigen: Durch die eingetretenen Verzögerungen (gemessen an den Projektplänen im Sommer 2010) bei der abschließenden Detailspezifikation der Schnittstelle („ION-Schnittstelle“) zur zentralen Vermittlungsstelle durch die VDV KA-KG und ATOS, wird das vHGS zum Systemstart die zentrale Vermittlungsstelle nicht nutzen. Auf Seiten des vHGS werden Maßnahmen ergriffen, um dies zu kompensieren. Dies beinhaltet unter anderem:

 Es wird ein „Stellvertreter-AHS“ implementiert, das zum einen vom vHGS die TXAA, TXRA und TXSNAWA erhält und speichert, zum anderen Sperranfragen für SAMs und Organisationen entgegennimmt.

 Es wird ein „Stellvertreter-AH-KOSES“ implementiert, so dass für das eTicket RheinMain ein vollständiges Sperrmanagement für Berechtigungen, Nutzermediumapplikationen, Schlüssel, SAMs und Organisationen vorhanden ist.

Version: 1.3 Datum: 04.10.2011 Datei: 11-12-08 Anlage 6_ExtMandant_Konzept_v1.4_Endversion.docSeite 4 von 13 Cubic Transportation Systems (Deutschland) GmbH, Vertraulich

[Seite 50]

vHGS eTicket RheinMain Konzept - Externer Mandant

 Die in den o.g. „Stellvertreter“-Systemen gespeicherten Daten können im Zuge der späteren Integration mit den zentralen Systemen der VDV-KA KG verwendet werden, um dort als historische Daten eingespielt zu werden.

3.2 Datenflüsse (KA Transaktionsdatensätze)

Die Schnittstelle zwischen vHGS und VU-HGS soll sich auf die für das Sperrmanagement und das Aktionsmanagement zwingend erforderlichen Daten beschränken. D.h.

 Sperrmanagement – Berechtigungen (RMV-EFS) Jedoch ohne Sperranfragen und Sperraufhebungsanforderungen. Sofern es einen Bedarf gibt, eine fremde Berechtigung zu sperren, muss die Sperranfrage organisatorisch (Telefon, E-Mail) übermittelt werden.

 Sperrmanagement – NmApplikation (eTicket RheinMain Nutzermedium) Jedoch ohne Sperranfragen und Sperraufhebungsanforderungen. Sofern es einen Bedarf gibt, ein fremdes Nutzermedium zu sperren, muss die Sperranfrage organisatorisch (Telefon, E-Mail) übermittelt werden.

 Sperrmanagement – KEY Jedoch ohne Sperranfragen und Sperraufhebungsanforderungen. Sofern es einen Bedarf gibt, einen fremden Sicherheitsschlüssel zu sperren, muss die Sperranfrage organisatorisch (Telefon, E-Mail) übermittelt werden.

 Sperrmanagement – SAM, ORG Jedoch ohne Sperranfragen und Sperraufhebungsanforderungen. Sperranfragen und Sperraufhebungsanforderungen für SAMs und ORGs sind von der VGF bzw. HEAG per E-Mail oder Fax an die übergeordnete fachliche Betriebsführung (üfB) des vHGS (vgl. Anlage 2 „Regelwerk vHGS“, Kap. 2.2 u. 3) zu richten. Sperraufträge für SAMs und ORGs werden gemäß KA Spezifikation vom AH erstellt. Für das AH-Stellvertretersystem ist dies so gelöst, dass das AH-Stellvertretersystem auf eine Sperranfrage SAM bzw. ORG immer einen entsprechenden Sperrauftrag erzeugt.

 Aktionsmanagement (RMV-EFS) Nachfolgend sind die auszutauschenden KA Transaktionsdaten tabellarisch dargestellt. Bzgl. der Kennzeichnung als „synchron“ / „asynchron“ siehe Kap. 3.4.

3.2.1 Sperrmanagement – Berechtigungen (RMV-EFS)

Version: 1.3 Datum: 04.10.2011 Datei: 11-12-08 Anlage 6_ExtMandant_Konzept_v1.4_Endversion.docSeite 5 von 13 Cubic Transportation Systems (Deutschland) GmbH, Vertraulich

[Seite 51]

vHGS eTicket RheinMain Konzept - Externer Mandant

3.2.2 Sperrmanagement – NmApplikation (eTicket RheinMain Nutzermedium)

3.2.3 Sperrmanagement – KEY

Version: 1.3 Datum: 04.10.2011 Datei: 11-12-08 Anlage 6_ExtMandant_Konzept_v1.4_Endversion.docSeite 6 von 13 Cubic Transportation Systems (Deutschland) GmbH, Vertraulich

[Seite 52]

vHGS eTicket RheinMain Konzept - Externer Mandant

3.2.4 Sperrmanagement – SAM, ORG

3.2.5 Aktionsmanagement (RMV-EFS)

Version: 1.3 Datum: 04.10.2011 Datei: 11-12-08 Anlage 6_ExtMandant_Konzept_v1.4_Endversion.docSeite 7 von 13 Cubic Transportation Systems (Deutschland) GmbH, Vertraulich

[Seite 53]

vHGS eTicket RheinMain Konzept - Externer Mandant

Weiterleitung von >> TXABER >> Transaktionsnachweisen aus >> TXRBER >> Aktionsausführungen an den

TXSNAWB >> beauftragenden KVP asynchron

3.2.6 Quittungsnachrichten TXA, TXB Die Quittungsnachrichten TXA und TXB sind in den obigen Tabellen nicht dargestellt. Die Quittungsnachrichten sind entsprechend den Vorgaben der KA Spezifikation zu erzeugen und in einem eigenen Kommunikationsvorgang zu senden. Beispiel: VU-HGS sendet TXSAUFB an vHGS. vHGS quittiert zunächst nur die technisch erfolgreiche Übermittlung (per http-Rückgabewert „OK“). Nach inhaltlicher Prüfung und Verarbeitung im vHGS sendet vHGS ein TXB (bzw. TXA) an das VU-HGS.

3.3 Ergänzende Festlegungen

3.3.1 TX_BASE, Signatur Es wird der TX_BASE gemäß KA Spezifikationsversion 1.107 verwendet. Die seitdem vorgenommenen Weiterentwicklungen (siehe KA CR 100) werden nicht berücksichtigt. Die Signaturattribute transSignaturTyp, transSignaturZertifikat und transSignatur werden nicht verwendet. Diese Attribute werden nicht gefüllt.

3.3.2 TX_BASE, Adressierung der KA-Nachrichten

In der Schnittstelle werden zur Adressierung die Sender- und Empfängerattribute des TX_BASE verwendet. D.h. an dieser Stelle werden die Org-IDs des RMV sowie der VGF bzw. der HEAG verwendet. Wie in Kap. 0 beschrieben, verwenden die Nutzermedien (KA Nutzermediumapplikation) und eTickets (KA Berechtigung, RMV EFS) als KVP-ID die ID der RMV KVP-Agentur; die Sender- und Empfängerattribute des TX_BASE dienen ausschließlich der Adressierung. Mit Bezug auf die Bezeichnungen in den Tabellen in Abschnitt 3.2 ergeben sich folgende Adressierungen:

Version: 1.3 Datum: 04.10.2011 Datei: 11-12-08 Anlage 6_ExtMandant_Konzept_v1.4_Endversion.docSeite 8 von 13 Cubic Transportation Systems (Deutschland) GmbH, Vertraulich

[Seite 54]

vHGS eTicket RheinMain Konzept - Externer Mandant

3.3.3 Sperrlisten Das vHGS stellt alle innerhalb des eTicket RheinMain erforderlichen Sperrlisten bereit. Bis zum Anschluss an das ION enthält die TXSLNM nur Einträge für eTicket RheinMain Nutzermedien, die TXSLK nur Einträge für eTicket RheinMain Schlüssel und die TXSLOS nur Einträge für eTicket RheinMain SAMs und Organisationen. Die Bereitstellung der Sperrlisten an der Schnittstelle erfolgt immer als Gesamtliste (keine Differenzlisten). Eine Konfiguration des KOSE ist nicht erforderlich (per Definition erhält jeder Nutzer des vHGS KOSE die Berechtigungssperren aller RMV-Produkte).

3.3.4 Defekte Medien Die Meldung defekter Medien und deren Sperrung ist ein wichtiges Element zum Schutz des Gesamtsystems vor Missbrauch. Da auf die automatisierte Übermittlung von Sperranfragen verzichtet wird, müssen als defekt gemeldete Medien, für die nicht im eigenen System der Sperrauftrag erzeugt werden kann, per E-Mail oder Fax an das zuständige System übermittelt werden, so dass dort der Sperrauftrag eingegeben werden kann. Dabei dient die übergeordnete fachliche Betriebsführung des vHGS als Klärungsstelle, da sie anhand der in das vHGS importierten Nutzermedienlieferlisten ermitteln kann, ob ein Nutzermedium von der VGF, der HEAG oder einem der vHGS-Mandanten in Umlauf gebracht wurde. Es ergibt sich folgender Prozess:

 Wird bei der VGF ein defektes Nutzermedium registriert, das von der VGF ausgegeben wurde, dann erstellt die VGF einen Sperrauftrag (TXSAUFA).

 Wird bei der VGF ein defektes Nutzermedium registriert, das nicht von der VGF ausgegeben wurde, dann übermittelt die VGF die aufgedruckte Nummer des Nutzermediums per E-Mail oder Fax an die übergeordnete fachliche Betriebsführung des vHGS. Diese ermittelt anhand der Nutzermediennummer, durch wen das als defekt gemeldete Nutzermedium ausgegeben wurde.

 Falls HEAG: Übermittlung der Nutzermediennummer per E-Mail oder Fax an die HEAG.

 Falls vHGS-Mandant: Eingabe einer Sperranfrage in das vHGS. Der betroffene Mandant erstellt daraufhin den Sperrauftrag (TXSAUFA).

 Die bei der HEAG anzuwendende Verfahrensweise ist analog zu der bei VGF.

 Wird bei einem der vHGS-Mandanten ein defektes Nutzermedium registriert, das von einem der vHGS-Mandanten ausgegeben wurde, dann wird innerhalb des vHGS eine Sperranfrage und in der Folge ein Sperrauftrag (TXSAUFA) erstellt.

 Wird bei einem der vHGS-Mandanten ein defektes Nutzermedium registriert, das nicht von einem der vHGS-Mandanten ausgegeben wurde, dann übermittelt der Mandant die aufgedruckte Nutzermediennummer per E-Mail oder Fax an die übergeordnete fachliche Betriebsführung des vHGS. Diese ermittelt anhand der Nutzermediennummer, durch wen (VGF oder HEAG) das als defekt gemeldete Nutzermedium ausgegeben wurde und übermittelt die Meldung des defekten Nutzermediums (mit Angabe der aufgedruckten Nutzermediennummer) per E-Mail oder Fax an VGF bzw. HEAG. Dementsprechend müssen sowohl das vHGS als auch die VU-HGS darauf vorbereitet sein, dass die Nutzermediennummer eines defekten Nutzermediums nicht im eigenen Datenbestand gefunden wird. Idealerweise weist das System in diesem Fall den Mitarbeiter darauf hin, wie der Fall weiter zu verfolgen ist (siehe oben).

Version: 1.3 Datum: 04.10.2011 Datei: 11-12-08 Anlage 6_ExtMandant_Konzept_v1.4_Endversion.docSeite 9 von 13 Cubic Transportation Systems (Deutschland) GmbH, Vertraulich

[Seite 55]

vHGS eTicket RheinMain Konzept - Externer Mandant

3.3.5 Übermittlung TXSNAWA vom AH-KOSE an den KVP In KA Version 1.106 wurden APP-Sperrnachweise (TXSNAWA), die aus APP-Sperraufträgen resultierten, nach ihrem Eintreffen vom KOSE an den KVP der gesperrten NmApplikation weitergeleitet. In der KA Version 1.107 wurde dies dahingehend geändert, dass die Sperrnachweise abgeholt werden, d.h. das KVPS sendet ein TXAS an den AH-KOSE und erhält daraufhin die TXSNAWA zugesendet. In der KA Version 1.107 wurde kein Listenformat definiert, das analog dem Herunterladen einer Sperrliste als Antwort zurückgegeben werden könnte. Seitens des vHGS wird folgendes Verfahren implementiert:

 Das KVPS sendet die Aufforderung zum Senden (TXAS mit Auftragscode 8).

 Das AH-KOSES sendet die seit der letzten Abholung neu eingetroffenen TXSNAWA einzeln nacheinander an das KVPS.

3.4 Technische Festlegungen zur Schnittstelle

Die Schnittstelle zwischen vHGS und den VU-HGS wird durch REST-Webservices implementiert. Als Kommunikationsprotokoll wird HTTPS eingesetzt. Das aufrufende System authentisiert sich nach Aufbau der HTTPS-Verbindung mittels Benutzername und Kennwort. Dabei ist der „Benutzer“ das aufrufende System. Der eingesetzte Mechanismus ist die Basic Authentication des HTTP-Protokolls. Die nachfolgende Abbildung gibt einen Überblick über den Aufbau.

vHGSRechenzentrum

re .../ e d h c t a p https://hgs.vu1.de/... vHGS-KOSE .v m s iD …/KaMessageRecipient VU1-HGS r.s g e g a (KVP, DL) hs v / / s e M :sa pK vHGS-Kern vHGS- t t h / … (PV, KVP, DL) Dispatcher

vHGS-AKS VU2-HGS (KVP, DL) (AH, AH- https://hgs.vu2.de/... KOSE) …/KaMessageRecipient

Das vHGS bietet den VU-HGS einen Service „KaMessageDispatcher“ an, über den das System des externen Mandanten KA-Nachrichten einreicht. Der Dispatcher leitet die eingehende Nachricht an das vHGS-Kern-System oder das AH/AH-KOSE-Stellvertreter-System weiter. Die Weiterleitung erfolgt anhand der Empfänger-Attribute (Org-ID und Rolle) im TX_BASE der KA- Nachricht. Der Dispatcher hat dabei keine Pufferfunktion, sondern arbeitet wie eine Telefonvermittlung: der eingehende Aufruf wird gehalten und an das Zielsystem weitergegeben; antwortet das Zielsystem nicht, wird dies dem Aufrufer per http-Fehlercode mitgeteilt. Die VU-HGS bieten dem vHGS einen Service „KaMessageRecipient“ an, über den das vHGS KA-Nachrichten einreicht.

Version: 1.3 Datum: 04.10.2011 Datei: 11-12-08 Anlage 6_ExtMandant_Konzept_v1.4_Endversion.docSeite 10 von 13 Cubic Transportation Systems (Deutschland) GmbH, Vertraulich

[Seite 56]

vHGS eTicket RheinMain Konzept - Externer Mandant

Die in der Abbildung gezeigten URLs müssen noch im Detail festgelegt werden. Die VU-HGS können die von Ihnen angebotene URL des „KaMessageRecipient“ frei wählen. Im vHGS wird für die KA Org-ID und KA-Rolle(n) jeweils die Ziel-URL des jeweiligen VU-HGS konfiguriert. Das vHGS und die VU-HGS müssen ständig über die Schnittstelle ansprechbar sein. Für den Fall von planmäßigen (Wartungsarbeiten) oder außerplanmäßigen Zeiten der Nichtverfügbarkeit eines Systems, ist in allen Systemen eine Fehlerbehandlung zu implementieren, die nach einem gescheiterten Verbindungsversuch erneut versucht, die Verbindung aufzubauen. Die erste Wiederholung darf und soll unverzüglich (innerhalb einer Minute) erfolgen. Für alle weiteren Versuche ist ein größerer Zeitabstand zu wählen. Als Empfehlung für sinnvolle Zeitabstände werden dabei die entsprechenden Regelungen aus den Spezifikationen des KA- ION angesehen. Sofern eines der Systeme einen Stapel von Nachrichten (z.B. weil es aufgrund einer Nichtverfügbakeit des Systems einen Rückstau gegeben hat) an ein anderes System zu versenden hat, wird es die Nachrichten des Stapels nacheinander versenden. Der HTTPS-Aufruf erfolgt immer mit dem HTTP-Verb POST und die KA-Nachricht wird als Parameter vom Typ text/xml übergeben. Als Rückgabewert wird entweder einer der HTTP-Standardrückgabewerte geliefert (z.B. 200 „OK“) oder eine KA XML-Datenstruktur (siehe nachfolgende Beschreibung). In Bezug auf die Rückgabewerte der Schnittstellenaufrufe und damit letztlich den Kommunikationsablauf zur Abwicklung eines Anwendungsfalls wird in Anlehnung an die ION- Spezifikation zwischen fachlich synchroner und fachlich asynchroner KA-Kommunikation unterschieden:

 Fachlich asynchroner KA-Datenaustausch: Übermittlung eines Transaktionsdatensatzes, der vom Empfänger mit TXA/TXB fachlich quittiert wird. Beispiel: Übermittlung eines Sperrauftrags TXSAUFA an den KOSE. Alle Datenflüsse, die gemäß dem asynchronen Muster abgewickelt werden, sind in den Tabellen in Kap. 3.2 mit dem Wort „asynchron“ gekennzeichnet.

 Fachlich synchroner KA-Datenaustausch: Abfrage von Daten. Beispiel: Sperrliste TXSLNM herunterladen. Alle Datenflüsse, die gemäß dem synchronen Muster abgewickelt werden, sind in den Tabellen in Kap. 3.2 mit dem Wort „synchron“ gekennzeichnet. Ablauf für fachlich asynchrone KA-Nachrichten vom VU-HGS an das vHGS:

 VU-HGS ruft https://vhgs.rmv.de/.../KaMessageDispatcher auf und übergibt dabei die KA- Nachricht TXyyy. Rückgabewert des Aufrufs ist http OK (oder ggf. ein http-Fehlercode).

 Nach fachlicher Prüfung und Verarbeitung der KA-Nachricht TXyyy im vHGS ruft das vHGS https://hgs.vu.de/.../KaMessageRecipient auf und übergibt dabei TXA bzw. TXB. Rückgabewert des Aufrufs ist http OK (oder ggf. ein http-Fehlercode). Der Ablauf für fachlich asynchrone KA-Nachrichten vom vHGS an ein VU-HGS ist analog. Ablauf für fachlich synchrone KA-Nachrichten vom VU-HGS an das vHGS:

 VU-HGS ruft https://vhgs.rmv.de/.../KaMessageDispatcher auf und übergibt dabei die KA- Nachricht TXaaa. Rückgabewert des Aufrufs ist die KA-Datenstruktur (xml) mit den abgefragten Daten (oder ggf. ein http-Fehlercode).

3.5 KA XML-Schema Als KA XML-Schema wird

Version: 1.3 Datum: 04.10.2011 Datei: 11-12-08 Anlage 6_ExtMandant_Konzept_v1.4_Endversion.docSeite 11 von 13 Cubic Transportation Systems (Deutschland) GmbH, Vertraulich

[Seite 57]

vHGS eTicket RheinMain Konzept - Externer Mandant

 KA_XML-Schema_V1107_K20110801.xsd verwendet. Soweit in der genannten XSD noch Fehler entdeckt werden, wird eine entsprechend korrigierte Folgeversion eingesetzt.

3.6 Sonderfallbehandlung für externe Mandanten im vHGS

Die Verwendung der KVP-ID der RMV KVP-Agentur durch externe Systeme (ohne Datensynchronisation im Sinne der bidirektionalen Schnittstelle) erfordert im vHGS eine Erweiterung der Datenverarbeitungsregeln. Bislang gab es externe KVP/DL (die ihre eigene Org-ID verwenden und gemäß den Regeln der KA mit dem PV, KOSE, KVP, DL im vHGS kommunizieren) und vHGS-Mandanten (die als Mitglieder der eTicket RheinMain KVP-Agentur/ DL-Agentur die Org ID des RMV verwenden). Durch die Anbindung der VGF und der HEAG als externe Mandanten über die in den vorangegangenen Abschnitten beschriebene Schnittstelle, müssen die nachfolgend beschriebenen Sonderfallbehandlungen implementiert werden. Die im vHGS erforderlichen Sonderfallbehandlungen für externe Mandanten (VGF, HEAG) bauen darauf auf, dass im vHGS eine Liste mit den Org-IDs der externen Mandanten eingerichtet wird. Den Org-IDs der externen Mandanten werden Nummernkreise für Nutzermedien (Nutzermedium-ID, NmAppinstanz-ID) und Berechtigungen (Berechtigung-ID) zugewiesen. Diese Nummernkreise sind in allen beteiligten Systemen (VGF, HEAG, vHGS) bei der Ausgabe von Nutzermedien und Berechtigungen zwingend zu beachten. Sonderfallbehandlung für von VGF bzw. HEAG ausgegebene Nutzermedien und Berechtigungen, wenn diese am Kartenleser der pVks eingelesen werden: Das vHGS muss erkennen, dass diese trotz RMV KVP Agentur ID als „extern verwaltete“ Nutzermedien bzw. Berechtigungen nicht im Service durch Dritte bearbeitet werden dürfen. Sonderfallbehandlung bei der Weiterleitung von Sperrnachweisen: Das vHGS muss erkennen, dass diese Nachweise obwohl sie sich auf Berechtigungen bzw. NmApplikationen beziehen, die die RMV KVP-Agentur ID als KVP-ID verwenden, an ein externes System (VU-HGS der VGF bzw. HEAG) weiter zu leiten sind. Sonderfallbehandlung bei der Weiterleitung von Transaktionsnachweisen aus Aktionsausführung: Das vHGS muss erkennen, dass diese Nachweise obwohl sie sich auf Berechtigungen beziehen, die die RMV KVP-Agentur ID als KVP-ID verwenden, an ein externes System (VU-HGS der VGF bzw. HEAG) weiter zu leiten sind. Für das Senden und Empfangen von KA-Transaktionsdatensätzen, muss das vHGS damit umgehen können, dass Sender- bzw. Empfänger-Org-ID im TX_BASE und Org-ID des Transaktionsgegenstands voneinander abweichen, wo sie gemäß KA-Spezifikation übereinstimmen würden (z.B. KVP-ID in der Berechtigung-ID eines TXSAUFB stimmt mit Org- ID des Senders überein). Sonderfallbehandlung bei der Erfassung defekter Medien, insbesondere auch Verarbeitung der TXKNAWDM aus den Kontrollgeräten: Das vHGS muss erkennen, wenn im vHGS eingegangene Kontrollnachweise TXKNAWDM Nutzermedien betreffen, die von VGF oder HEAG ausgegeben wurden. Die Daten sind in einer gesonderten Liste auszuweisen, so dass sie per Telefon/Fax/E-Mail an VGF bzw. HEAG übermittelt werden können, damit dort entsprechende Sperraufträge eingegeben werden können. Umgekehrt müssen auch VGF und HEAG entsprechende Listen an die üfB übermitteln. Die Betrugsanalyse (Transaktionsprüfungen des PV gemäß KA Verfahrensanweisung sowie weitere automatisierte Datenauswertungen im vHGS zur Identifizierung von potentiellen Betrugsversuchen) muss dahingehend geändert werden, dass im vHGS eingegangene Kontrollnachweise (TXEBER), die sich auf Berechtigungen beziehen, die von VGF bzw. HEAG ausgegeben wurden, nicht darauf geprüft werden, ob für die entsprechende Berechtigung der

Version: 1.3 Datum: 04.10.2011 Datei: 11-12-08 Anlage 6_ExtMandant_Konzept_v1.4_Endversion.docSeite 12 von 13 Cubic Transportation Systems (Deutschland) GmbH, Vertraulich

[Seite 58]

vHGS eTicket RheinMain Konzept - Externer Mandant

Ausgabenachweis vorliegt. Weiterhin kann für alle Berechtigungen nicht mehr geprüft, werden, ob die Transaktionen (berLogSeqNummer, berSyncronNummer)) lückenlos vorliegen.

4 Bewertung im Hinblick auf das Sicherheitsmanagement

Das KA-Sicherheitssystem besteht aus zwei Elementen:

1. Ein auf anerkannte kryptografische Verfahren gestützter Schutzmechanismus, der die Echtheit und Unverfälschtheit der Transaktionsdaten gewährleisten soll.
2. Eine Überwachung, ob der Schutzmechanismus intakt ist. Das in diesem Dokument beschriebene Konzept zur Schnittstelle zwischen VGF/HEAG und dem vHGS schwächt die kryptografischen Verfahren nicht. Einschränkungen gibt es jedoch im Bereich der Überwachung. Die Einschränkungen betreffen die folgenden von der KA vorgesehenen Prüfungen des RMV als PV für eTicket RheinMain Berechtigungen (RMV-EFS):

 Ausgabetransaktion TXABER liegt vor Dies kann für Berechtigungen, die von VGF bzw. HEAG ausgegeben wurden, nicht geprüft werden.

 Lückenlosigkeit der berLogSeqNummer Dies kann für alle Berechtigungen nicht geprüft werden. Es sind jedoch damit verwandte Prüfungen (doppelt auftretende berLogSeqNummer, auffällig große Lücken) anhand der Daten möglich, die dem PV von den vHGS-Mandanten geliefert werden.

 Lückenlosigkeit der berSynchronNummer Dies kann für Berechtigungen, die von VGF bzw. HEAG ausgegeben wurden, nicht geprüft werden. Die oben genannten Einschränkungen sind für eine Übergangszeit vertretbar, insbesondere wenn VGF und HEAG in ihren Systemen für die von Ihnen ausgegebenen Berechtigungen die Eigenschaften „Ausgabetransaktion TXABER liegt vor“ und „Lückenlosigkeit der berSynchronNummer“ überwachen. Der am leichtesten realisierbare Betrugsversuch durch Nutzer ist die Verwendung defekter Nutzermedien sowie die „Duplizierung“ von Nutzermedien durch Ersatznutzermedien aus einer Verlust-/Defektmeldung. Das Erfassen defekter Nutzermedien bei den Kontrollen und das anschließende Erstellen von Sperraufträgen sowie die Nachprüfung (EBE-Androhung), ob das defekte Nutzermedium eine gültige Fahrberechtigung enthielt, sollte daher möglichst konsequent umgesetzt werden. Die durch den gewählten Zuschnitt der Schnittstelle zwischen vHGS und den Systemen der VGF und der HEAG bestehenden Einschränkungen können durch organisatorische Maßnahmen (Erstellung und Austausch von Listen, telefonische Klärung von Verdachtsfällen) ausgeglichen werden.

Version: 1.3 Datum: 04.10.2011 Datei: 11-12-08 Anlage 6_ExtMandant_Konzept_v1.4_Endversion.docSeite 13 von 13 Cubic Transportation Systems (Deutschland) GmbH, Vertraulich

[Seite 59]

Teil II: Vertrieb & Service (Bidi II: Service durch Dritte und

Internetvertrieb)

Versionsverwaltung

21-10-01 Anlage 3 zum vHGS-Vertrag Konzept Externe Mandanten

[Seite 60]

eTicket RheinMain

Schnittstellenspezifikation

vHGS / Externe Mandanten - Bidirektionale

Schnittstelle

Vertrieb & Service

Version: 2.4 Datum: 14.09.2018 Dok-Ref.: SST_ExtM-BD_VS Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4.docx

[Seite 61]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

Versionshistorie

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 1 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 62]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

Verteiler

Urheberrecht und Vertraulichkeit

Copyright von Cubic Transportation Systems (Deutschland) GmbH 2018. Alle Rechte vorbehalten.

Das Urheberrecht an dieser Arbeit ist Eigentum von Cubic Transportation Systems (Deutschland) GmbH.

Diese Arbeit wurde von Cubic im Auftrag der rms im Rahmen des Projekts eTicket RheinMain vHGS erstellt. Diese Arbeit (vollständig oder in Auszügen) darf nicht ohne die vorherige schriftliche Zustimmung von Cubic Transportation Systems (Deutschland) GmbH für andere Zwecke, als für jene, für die sie vorgelegt wurde, vervielfältigt, veröffentlicht oder an Dritte weitergegeben oder anderweitig verwendet werden.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 2 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 63]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

Inhalt

1 Einleitung ........................................................................................................................... 6 2 Anforderungen und fachliche Festlegungen ................................................................... 7

2.1 Allgemein ..................................................................................................................... 7 2.2 Realisierungsstufen ...................................................................................................... 8 3 Schnittstelle Externes Portal (Webshop) ......................................................................... 9

3.1 Allgemein ..................................................................................................................... 9 3.1.1 Systemarchitektur ................................................................................................. 9 3.1.2 Registrierung in einem Internetportal ..................................................................... 9 3.1.3 Zuordnung von Bestellungen und Serviceanliegen .............................................. 10 3.1.4 RMVsmiles .......................................................................................................... 11 3.1.5 Kundenkommunikation ........................................................................................ 11 3.2 Anwendungsfälle für den Service über Internetportale ............................................... 12 3.2.1 Registrierung Chipkarte [kein Anwendungsfall für bidirektionale SST] ................. 12 3.2.2 Bestellung Ersatzchipkarte .................................................................................. 12 3.2.3 Anzeige aller Fahrkarten zu einer Chipkarte ........................................................ 13 3.2.4 Anzeige der Berechtigungsnachweise zu einer Chipkarte [kein Anwendungsfall für bidirektionale SST] ............................................................................................................ 14 3.2.5 Verkauf von Barfahrkarten auf fremde Chipkarten ............................................... 14 3.2.6 Erfassung und Ausgabe von Berechtigungsnachweisen [kein Anwendungsfall] .. 15 4 Schnittstelle Service durch Dritte (personalbedient) .................................................... 16 4.1 Allgemein ................................................................................................................... 16 4.2 Anwendungsfälle für den Service durch Dritte ............................................................ 16 4.2.1 Bestellung Ersatzchipkarte .................................................................................. 16 4.2.2 Erfassung und Ausgabe von Berechtigungsnachweisen ..................................... 18 4.2.3 Anzeige aller Fahrkarten zu einer Chipkarte ........................................................ 19 4.2.4 Prüfung auf gültige Fahrkarte für die Erstattung von Ersatzfahrkarten ................. 19 4.2.5 Prüfung auf gültige Fahrkarte für die Klärung eines EBE-Falles .......................... 20 5 Schnittstellenfunktionen und Datenstrukturen ............................................................. 21

5.1 Allgemeine Festlegungen ........................................................................................... 21 5.1.1 SOAP-Webservices............................................................................................. 21 5.1.2 Timeouts ............................................................................................................. 21 5.1.3 SOAP-Fault ......................................................................................................... 21 5.1.4 Identifikatoren (IDs) ............................................................................................. 21 5.1.5 KA-Datenstrukturen ............................................................................................. 22 5.2 Mehrfach verwendbare Datenstrukturen ..................................................................... 22 5.2.1 AnfrageQuelle ..................................................................................................... 22 5.2.2 Adresse ............................................................................................................... 23 5.2.3 TicketDaten ......................................................................................................... 23 5.2.4 KundendatenNm ................................................................................................. 24 5.2.5 TXAGBBER_Auftrag_Ber .................................................................................... 25 5.2.6 TXABER_Daten .................................................................................................. 26 5.2.7 TXAGBBER_Auftrag_App ................................................................................... 27 5.2.8 TXAGBKUNDE_Auftrag ...................................................................................... 28 5.2.9 TXAGBPINPUC_Auftrag ..................................................................................... 28 5.2.10 TXAA_Daten ....................................................................................................... 29 5.3 Schnittstellenfunktionen.............................................................................................. 29

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 3 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 64]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

5.3.1 ermittleTicketDatenFuerChipkarte ....................................................................... 29 5.3.2 ermittleChipkartenDaten ...................................................................................... 30 5.3.3 findeChipkarteFuerNutzer ................................................................................... 32 5.3.4 liefereTicketsFuerErsatzChipkarte ....................................................................... 33 5.3.5 ticketAusgegebenAufErsatzChipkarte ................................................................. 34 5.3.6 liefereErsatzChipkarteAusgabe ........................................................................... 35 5.3.7 ersatzChipkarteAusgegeben ............................................................................... 36 5.3.8 zustaendigkeitFuerChipkarteUebergeben ........................................................... 37 5.3.9 ermittleBerNwKundendatenFuerCk ..................................................................... 38 5.3.10 aktualisiereBerNwKundendaten .......................................................................... 39 5.3.11 berechtigungsnachweisAusgegeben ................................................................... 39

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 4 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 65]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

Referenzdokumente

[FK_BD-SST] eTicket RheinMain Fachkonzept Bidirektionale Schnittstelle rms, Version 2.0, 25.01.2016 [SST-ExtM-BD_HD] eTicket RheinMain Schnittstellenspezifikation Bidirektionale Schnittstelle, Hauptdokument Cubic, Version 2.3, 11.10.2016 [KA_SPEC] KA Spezifikationen VDV ETS, Version 1.3.0, Juni 2014 [SPEC-KDNM] eTicket RheinMain Spezifikation Kundendaten auf dem Nutzermedium Cubic, Version 1.6, 25.01.2016 [vHGS_PH05-A1] Verbundweites mandantenfähiges Hintergrundsystem eTicket RheinMain (vHGS) Pflichtenheft 05 Anhang 1 RMV-EFS Cubic, Version 1.5, 15.05.2012

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 5 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 66]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

1 Einleitung

Dieses Dokument ist Teil der Schnittstellenspezifikation vHGS / Externe Mandanten. In diesem Dokument werden die Schnittstellenfunktionen zur Implementierung systemübergreifender Services im Internetvertrieb und in den Kundenservicestellen (Service durch Dritte) spezifiziert. Die Einordnung in den Kontext des Gesamtsystems eTicket RheinMain, die allgemeine Aufgabenstellung für die Schnittstelle sowie allgemeine technische Randbedingungen und Festlegungen sind dem Hauptdokument der Schnittstellenspezifikation [SST_ExtM-BD_HD] zu entnehmen.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 6 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 67]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

2 Anforderungen und fachliche Festlegungen

2.1 Allgemein

Die fachlichen Anforderungen und Detailfestlegungen sind im Fachkonzept Bidirektionale Schnittstelle [FK_BD-SST] beschrieben. Insbesondere sind darin auch die im Internetvertrieb und im Service durch Dritte jeweils zu unterstützenden Anwendungsfälle in einer abschließenden Aufzählung mit produktspezifischen Abgrenzungen benannt. Das Hauptdokument [SST_ExtM-BD_HD] der Schnittstellenspezifikation enthält ergänzende Festlegungen und Präzisierungen im Hinblick auf allgemeine Aspekte der technischen Umsetzung der fachlichen Anforderungen. Insbesondere sind im Hauptdokument die fachlichen Randbedingungen beschrieben, die gegenüber der Spezifikation aus dem Jahr 2013 eine signifikante Vereinfachung der technischen Umsetzung erlauben. Anschaulich formuliert ergeben sich daraus folgende Vereinfachungen:

 Folgechipkarten: Die Entscheidung über die Erstellung einer Folgechipkarte liegt in dem System (vHGS oder eines der HGS der externen Mandanten), das die ablaufende Chipkarte ausgegeben hat und verwaltet. Auch für die Erstellung der Folgechipkarte brauchen keine Daten aus den anderen Systemen angefordert werden.

 Die bidirektionale Schnittstelle benötigt keine Funktionen zur Unterstützung des Folgechipkartenprozesses.

 Internetportal / Registrierung und Services: Die externen Mandanten betreiben eigene internetbasierte Kundenportale. Die vHGS-Mandanten nutzen das internetbasierte Kundenportal des RMV. Der Kunde kann seine Chipkarte nur in dem internetbasierten Kundenportal des Mandanten registrieren und verwalten, von dem er die Chipkarte erhalten hat.

 Die bidirektionale Schnittstelle benötigt keine Funktionen zur Unterstützung der Registrierung einer Chipkarte in einem internetbasierten Kundenportal und auch keine Funktionen zur Änderung von Kunden- und Vertragsdaten.

 Ersatzchipkarten: Die Ausstellung einer Ersatzchipkarte soll die Zuständigkeit des Hintergrundsystems für die spätere Ausstellung einer etwaigen Folgechipkarte nicht brechen.

 Für die, weiterhin gewünschte, Ausstellung einer Ersatzchipkarte im systemübergreifenden Service durch Dritte bedeutet dies, dass die Verantwortung für die ausgestellte Ersatzchipkarte an den Mandanten zu übergeben ist, der die ersetzte Chipkarte ausgegeben hat.

 Die Bestellung einer Ersatzchipkarte über ein Internetportal ist nur in dem Internetportal möglich, in dem die zu ersetzende Chipkarte registriert wurde. Somit geht die Ersatzchipkartenbestellung immer an das Hintergrundsystem, das die zu ersetzende Chipkarte ausgegeben hat. Siehe auch Kapitel 2.3. und 2.4 des Hauptdokuments [SST_ExtM-BD_HD] zu den in den Hintergrundsystemen zu implementierenden Regeln, die als Voraussetzung benötigt werden.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 7 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 68]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

2.2 Realisierungsstufen

Die systemübergreifenden Services (im Service durch Dritte & im Internetvertrieb) sollen stufenweise entwickelt werden, wobei jeweils die Erfahrungen aus der Umsetzung einer Stufe in die Detailkonzeption und Umsetzung einer nächsten Stufe einfließen. Aktuell soll die Stufe 1 umgesetzt werden. Die Stufe 1 enthält gemäß [FK_BD-SST] die folgenden Servicefälle:

 Anzeige aller Fahrkarten und Berechtigungsnachweise externer und vHGS- Mandanten auf einer Chipkarte

 Ausgabe von Berechtigungsnachweisen

 Erstellung einer Ersatzchipkarte, auf der Fahrkarten und Berechtigungsnachweise von vHGS- und externen Mandanten vorhanden sind

 Verkauf von Barprodukten auf fremden Chipkarten

 Prüfung auf gültige Fahrkarte für die Erstattung von Ersatzfahrkarten bei defekten Chipkarten

 Prüfung auf gültige Fahrkarte für die Klärung eines EBE-Falles bei defekten Chipkarten Für die Stufe 2 sind gemäß [FK_BD-SST] die folgenden Servicefälle geplant:

 Erneute Bereitstellung der Begleitdokumente, die bei der Ausgabe der Chipkarte dem Kunden mitgegeben wurden

 Erneute Bereitstellung der Begleitdokumente, die beim Kauf einer Fahrkarte dem Kunden mitgegeben wurden

 Übertragen von einer Fahrkarte auf eine vorhandene Chipkarte

 Änderung von Kundendaten

 Erzeugen und Verwalten von Rabattgutscheinen für die WebShops

 Integration von RMV-Smiles Über die Umsetzung der Servicefälle der Stufe 2 ist noch nicht entschieden und sie sind im [FK_BD-SST] noch nicht ausgearbeitet und sind nicht Teil der [SST-ExtM-BD_VS].

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 8 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 69]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

3 Schnittstelle Externes Portal (Webshop)

3.1 Allgemein

3.1.1 Systemarchitektur

Wie im Hauptdokument der Schnittstellenspezifikation bereits dargestellt, kommunizieren die Internetportale direkt mit dem ihnen zugeordneten Hintergrundsystem. Die Schnittstelle zwischen einem Internetportal und dessen „Heimat-Hintergrundsystem“ ist nicht standardisiert und nicht Gegenstand dieses Dokuments. Die Hintergrundsysteme erkennen von ihnen nicht erfüllbare Aufrufe ihres Internetportals und setzen diese in Aufrufe an das zuständige Hintergrundsystem um. Dazu wendet sich das Hintergrundsystem an die vom vHGS bereitgestellte Service-Vermittlungsstelle (SVMS), welche den Aufruf an das zuständige Hintergrundsystem weiterleitet. Die Vermittlungsstelle beinhaltet keine Geschäftslogik. Vielmehr ist sie in der Lage, an Hand der KA-Organisations-ID eines Verkehrsunternehmens einen Aufruf an das zuständige Hintergrundsystem weiterzuleiten sowie bestimmte Aufrufe an alle Hintergrundsysteme zu verteilen und die Ergebnisse zusammenzuführen (Split/Join). Da die Verarbeitung ggf. an ein anderes Hintergrundsystem delegiert wird, muss eine saubere Trennung zwischen Internetportal und Verarbeitung im Heimat-Hintergrundsystem durchgehalten werden. Die Abwicklung einer Bestellung bzw. eines Serviceanliegens erfolgt durch das jeweilige Heimat-Hintergrundsystem. Das Internetportal erfasst alle erforderlichen Daten und übergibt diese an das Heimat-Hintergrundsystem. Alle Bestellungen und Servicefälle aus dem Internetportal müssen im Heimat- Hintergrundsystem, ggf. einschließlich der Delegation an ein fremdes Hintergrundsystem, protokolliert und nachvollziehbar dargestellt werden, vgl. diesbezügliche Festlegungen in [SST_ExtM-BD_HD].

3.1.2 Registrierung in einem Internetportal Bei der „Registrierung in einem Internetportal“ stellt der in einem Internetportal angemeldete Nutzer eine Verbindung zu den eTicket-Geschäftsobjekten (Verträge bzw. Fahrkarten, Chipkarten) her. Dazu verwendet er einen Registrierungsschlüssel, der ihn als rechtmäßigen Verwalter der jeweiligen Geschäftsobjekte legitimiert. Nach erfolgreicher Überprüfung des Registrierungsschlüssels ist der Internetportal-Nutzer als Verwalter der jeweiligen Geschäftsobjekte registriert. Wie in Kapitel 2.1 bereits beschrieben, soll der Kunde seine Chipkarte nur in dem internetbasierten Kundenportal des Mandanten registrieren und verwalten können, von dem er die Chipkarte erhalten hat. D.h. die Prüfung des Registrierungsschlüssels kann immer im Heimat-HGS des Internetportals erfolgen und der Vorgang erfordert keine systemübergreifenden Funktionen. Vor diesem Hintergrund hat die nachfolgende Beschreibung des zwischen meinRMV und dem vHGS implementierten Verfahrens lediglich informativen Charakter. Die externen Mandanten können abweichende Verfahren implementieren, müssen dabei jedoch sicherstellen, dass im Ergebnis die Registrierung der Chipkarte als „wird verwaltet von Internetportal-Nutzer X“ gegeben ist. Für das Zusammenspiel zwischen meinRMV und vHGS wurde ein so genanntes „Chipkartenverwalter-Modell“ konzipiert und implementiert. Dazu erzeugt das vHGS pro

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 9 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 70]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

Chipkarte einen Registrierungscode, der dem Karteninhaber bei der Ausgabe der Chipkarte (Anschreiben des Massenpersonalisierers bzw. Beleg aus dem vHGS) mitgeteilt wird. Der Karteninhaber ist dem vHGS ggf. nicht vorab bekannt (z.B. bei anonymer Ausgabe einer Chipkarte in einer Verkaufsstelle). Ein meinRMV-Nutzer kann sich durch Angabe der Chipkartennummer und des Registrierungscodes als Verwalter der Chipkarte und aller damit verbundenen Fahrkarten und Verträge registrieren. Dieser meinRMV-Nutzer (der „Chipkartenverwalter“) muss nicht identisch sein mit dem Karteninhaber oder Besteller eines Abo-Vertrags.

3.1.3 Zuordnung von Bestellungen und Serviceanliegen Serviceanliegen beziehen sich jeweils auf eine Fahrkarte oder auf eine Chipkarte. Die Abwicklung des Serviceanliegens wird also jeweils dem Verkehrsunternehmen zugeordnet, das der Vertragspartner für das Bezugsobjekt (Fahrkarte, Chipkarte) ist. Bestellungen beziehen sich jeweils auf eine neue Fahrkarte (Barprodukt oder Abbuchungsprodukt) ggf. in Verbindung mit einer neuen Chipkarte1. Für die Zuordnung von Bestellungen, die über das Internetportal des RMV eingegeben werden, ist im Internetportal des RMV eine Zuordnungsregel implementiert, die die Bestellung einem der vHGS-Mandanten zuordnet. Das vHGS erhält mit der Bestellung jeweils auch die Identifikation des ausführenden Verkehrsunternehmens. Bestellungen, die über das Internetportal eines VU eingegeben werden, werden immer dem Verkehrsunternehmen zugeordnet, dass das Internetportal betreibt. Die getroffenen Festlegungen zur Vereinfachung der bidirektionalen Schnittstelle für Verkauf & Service führen (beabsichtigterweise) dazu, dass …

 … Serviceanliegen in Bezug auf eine Chipkarte nur in dem Internetportal eingegeben werden können, dessen Heimat-Hintergrundsystem auch das Heimat-Hintergrundsystem der Chipkarte ist. Für die Bearbeitung einer Ersatzchipkartenbestellung muss das Heimat- Hintergrundsystem mit den übrigen Hintergrundsystemen kommunizieren.

 …Bestellungen für Vertragsprodukte (Abonnements, Schülerfahrkarten im Abbuchungsverfahren, JobTickets– eine verbindliche, detaillierte Liste wird vom RMV bereitgestellt und gepflegt) mit Auslieferung auf eine vorhandene Chipkarte nur in dem Internetportal eingegeben werden können, dessen Heimat-Hintergrundsystem auch das Heimat-Hintergrundsystem der Chipkarte ist. Die Bearbeitung der Bestellung erfolgt vollständig in dem Heimat-Hintergrundsystem.

 …Bestellungen für Vertragsprodukte mit Auslieferung einer neuen Chipkarte in einem beliebigen, vom Kunden gewählten Internetportal eingegeben werden können und im Heimat-Hintergrundsystem des Internetportals vollständig bearbeitet werden.

 … Serviceanliegen in Bezug auf Vertragsprodukte nur in dem Internetportal eingegeben werden können, dessen Heimat-Hintergrundsystem auch das Heimat-Hintergrundsystem der Chipkarte ist (weil gegeben ist, dass Vertragsprodukte immer im Heimat- Hintergrundsystem der Chipkarte verwaltet werden) und im Heimat-Hintergrundsystem des Internetportals vollständig bearbeitet werden.

 … Bestellungen für Bar-Produkte (Preis und Laufzeit stehen zum Zeitpunkt der Bestellung fest) sowohl mit Auslieferung auf eine vorhandene Chipkarte als auch mit Auslieferung einer neuen Chipkarte in einem beliebigen, vom Kunden gewählten Internetportal eingegeben

1 Sofern der Nutzer bereits über eine Chipkarte verfügt, die in dem Internetportal registriert wurde, kann er auch eine Fahrkarte für die bereits vorhandene Chipkarte bestellen.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 10 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 71]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

werden können und im Heimat-Hintergrundsystem des Internetportals vollständig bearbeitet werden.

Noch keine abschließende Festlegung wurde getroffen für …

 …Serviceanliegen in Bezug auf Bar-Produkte. Die bislang definierte Stufe 1 der bidirektionalen Schnittstelle Verkauf & Service enthält keine derartigen Servicefälle. Soweit die Verkehrsunternehmen die Eingabe von Serviceanliegen in Bezug auf Bar-Produkte über das Internet anbieten wollen, können sich diese vorerst nur auf Fahrkarten beziehen, die im Heimat-Hintergrundsystem des Internetportals verwaltet werden.

3.1.4 RMVsmiles Das Bonussystem RMVsmiles ist ein Anreizsystem zur Nutzung von meinRMV und den dort angebotenen Möglichkeiten des Onlinevertriebs. Die Anmeldung zu bzw. Abmeldung von dem Bonussystem RMVsmiles erfolgt über das Internetportal meinRMV. Die Meldung der bonusfähigen Umsätze an RMVsmiles erfolgt durch das Hintergrundsystem, in dem der bonusfähige Umsatz gebucht wurde. Aus den getroffenen Festlegungen zur Vereinfachung der bidirektionalen Schnittstelle für Verkauf & Service ergibt sich, dass bonusfähige Umsätze nur in dem Heimat- Hintergrundsystem von meinRMV, also dem vHGS, entstehen können. Vor diesem Hintergrund ist RMVsmiles für die bidirektionale Schnittstelle Verkauf & Service nicht relevant. Sofern RMVsmiles für andere Internetportale geöffnet wird, ist zu prüfen, ob dies Auswirkungen auf die bidirektionale Schnittstelle hat.

3.1.5 Kundenkommunikation

Für die Kommunikation des Verkehrsunternehmens mit dem Kunden müssen, mit Ausnahme der vertragsbezogenen Kommunikation per Post, Erlaubnisse (Permissions) des Kunden bzgl. der zulässigen Gegenstandsbereiche und auch der zulässigen Kommunikationskanäle eingeholt und verwaltet werden. Für die hier beschriebene Schnittstelle wird folgendes Modell verwendet.

In Bezug auf die Geschäftsbeziehung gilt:

 Die Kommunikation per Post ist immer möglich.

 Die Zustimmung zur Kommunikation per E-Mail bedeutet, dass das Verkehrsunternehmen geschäftsbezogene Schriftstücke, insbesondere auch SEPA-Vorankündigungen, per E-Mail zustellen kann und, dass der Kunde dies als Ersatz für die Schriftform akzeptiert. Für in einem Internetportal registrierte Chipkarten und in einem Internetportal eingegebene Bestellungen und Serviceanliegen kann unterstellt werden, dass die Einwilligung zur Kommunikation per E-Mail in Bezug auf die Geschäftsbeziehung gegeben ist.

 Sofern vom Kunden Telefonnummern angegeben wurden, gilt dies als Einverständnis, dass er telefonisch zur Klärung von Fragen kontaktiert werden kann. Vor dem Hintergrund der getroffenen Festlegungen zur Vereinfachung der Schnittstelle und des Leistungsumfangs der Stufe ist eine Übertragung der Kommunikationserlaubnisse an der

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 11 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 72]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

bidirektionalen Schnittstelle nicht erforderlich. Bei der Umsetzung weiterer Stufen kann sich dies ggf. ändern, so dass empfohlen wird, die Verwaltung der Kommunikationserlaubnisse in allen Hintergrundsystemen entsprechend der obigen Darstellung zu gestalten.

3.2 Anwendungsfälle für den Service über Internetportale

Der Servicekatalog für den Service über Internetportale ist im Fachkonzept [FK-BD-SST] festgelegt. Nachfolgend wird die Umsetzung der dort aufgeführten Servicefälle (=Anwendungsfälle) beschrieben.

3.2.1 Registrierung Chipkarte [kein Anwendungsfall für bidirektionale SST] Für die Registrierung der Chipkarte wird keine Funktion in der bidirektionalen Schnittstelle benötigt. Siehe Kapitel 3.1.2. Der Kunde kann seine Chipkarte nur in dem internetbasierten Kundenportal des Mandanten registrieren und verwalten, von dem er die Chipkarte erhalten hat.

Anmerkung / Hinweis zum Verständnis der Beschreibung der nachfolgenden Anwendungsfälle: Alle nachfolgenden Anwendungsfälle beginnen damit, dass sich der Kunde am Portal angemeldet hat. Dieses Portal ist also immer das internetbasierte Kundenportal des Mandanten, von dem der Kunde die Chipkarte erhalten hat. Und die Bearbeitung des Anwendungsfalls erfolgt damit immer in dem Heimat-HGS der Chipkarte, wobei das Heimat- HGS über die Bidirektionale Schnittstelle die Unterstützung der weiteren HGS anfordert.

3.2.2 Bestellung Ersatzchipkarte

Bei der Bestellung einer Ersatzchipkarte meldet sich der Nutzer am Portal an, wählt aus den im Portal registrierten Chipkarten die entsprechende Chipkarte aus und veranlasst die Bestellung der Ersatzchipkarte. Fachliche Details: Als Grund für die Bestellung einer Ersatzchipkarte ist von einem Verlust, Defekt oder Diebstahl der alten Chipkarte auszugehen. Die Ersatzchipkarte soll sofort gültig sein2 und die bisherige Chipkarte wird gesperrt (dies ist dem Kunden im Portal anzuzeigen). Für die Ausstellung einer Ersatzchipkarte wird entsprechend den Tarifbestimmungen des RMV von dem Unternehmen, dass die Ersatzchipkarte ausstellt, eine Servicegebühr erhoben. Die Abrechnung der Servicegebühr gegenüber dem Kunden erfolgt durch das Internetportal (ggf. im Zusammenspiel mit einem Shop-System dem Heimat-HGS des Portals). Die Ersatzchipkartenbestellung wird an das Heimat-HGS des Portals übergeben. Das Heimat-HGS legt eine Chipkartenbestellung für die Ersatzchipkarte an. Das Heimat-HGS fügt der Chipkartenbestellung die notwendigen Daten für das Schreiben der Berechtigungsnachweise (= Kundendaten auf dem NM) hinzu, die auf der bisherigen Chipkarte vorhanden waren. Die auf der bisherigen Chipkarte vorhandenen Berechtigungsnachweise liegen dem Heimat-HGS vollständig im eigenen Datenbestand vor.

2 Sofern es Restriktionen gibt, die als Startdatum einer Chipkarte bzw. einer Fahrkarte (Berechtigung) nicht beliebige Tage zulassen (sondern zum Beispiel nur den Monatsersten) muss ein geeigneter zurückliegendes Datum (zum Beispiel der Monatserste des laufenden Monats) verwendet werden.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 12 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 73]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

Das Heimat-HGS erzeugt Ersatzfahrkarten für die im Heimat-HGS verwalteten ersetzbaren Fahrkarten auf der bisherigen Chipkarte und ruft anschließend über die Vermittlungsstelle alle anderen Hintergrundsysteme auf, für die von ihnen verwalteten ersetzbaren Fahrkarten auf der bisherigen Chipkarte eine Ersatzfahrkarte zu liefern. Diese Funktion wird von der Vermittlungsstelle in der Form bereitgestellt, dass die Aufrufe parallel abgesetzt werden und die Teilergebnisse in einem Gesamtergebnis an den Aufrufer zurückgeliefert werden (Split/Join). Hierbei gilt die Regel, dass nicht innerhalb des vereinbarten Zeitfensters (Timeout) antwortende Systeme übergangen werden und nicht zum Abbruch der Aktion führen. Die Vermittlungsstelle liefert dem Hintergrundsystem, das für die Erstellung der Ersatzchipkarte zuständig ist, neben der Liste der Ersatzfahrkarten auch eine Liste der Hintergrundsysteme, die nicht geantwortet haben. Die fremden Hintergrundsysteme beantworten die Anfrage des Heimat-Hintergrundsystem mit einer Liste von Ausgabeaufträgen (TXAGBBER3) für die auf die Ersatzchipkarte aufzubringenden Ersatzfahrkarten. [Schnittstellenfunktion 5.3.4 liefereTicketsFuerErsatzChipkarte]

Sofern ein oder mehrere Hintergrundsysteme nicht geantwortet haben, soll das Hintergrundsystem, das für die Erstellung der Ersatzchipkarte zuständig ist, mindestens drei Wiederholungsversuche durchführen. Bei einem Wiederholungsversuch werden (über die Vermittlungsstelle) einzeln gezielt die Systeme anfragt, die bislang nicht geantwortet haben. Der letzte Wiederholungsversuch soll frühestens 24 Stunden nach der ersten Anfrage erfolgen. Sofern ein oder mehrere Hintergrundsysteme auch nach Ausschöpfung der Wiederholungsversuche nicht geantwortet haben, wird die Ersatzchipkartenbestellung dennoch ausgeführt. Nachdem die Antworten der fremden Hintergrundsysteme vorliegen (oder die Wiederholungsversuche ausgeschöpft sind) wird die Ersatzchipkartenbestellung vom Heimat- Hintergrundsystem ausgeführt und die Chipkarte an den Chipkarteninhaber verschickt. Ebenso ist das Heimat-Hintergrundsystem für das Sperren der alten Chipkarte und ggf.4 die Ausgabe einer Übergangschipkarte zuständig. Nach Erzeugung der Ersatzchipkarte übergibt das Heimat-Hintergrundsystem die Transaktionsnachweise (TXABER) aus der Ausgabe von Fahrkarten der fremden Hintergrundsysteme einzeln an die jeweiligen Hintergrundsysteme, die dadurch erfahren, auf welche Chipkarte (NmAppInstanz-ID und Chipkartennummer der Ersatzchipkarte) die Fahrkarte ausgegeben wurde. [Schnittstellenfunktion 5.3.5 ticketAusgegebenAufErsatzChipkarte] Diese TXABER werden von dem empfangenden System (von dem der jeweilige TXAGBBER kam) als KVPS verarbeitet und von dort an das PVS gesendet.

3.2.3 Anzeige aller Fahrkarten zu einer Chipkarte Der Nutzer hat sich am Portal angemeldet, hat aus den im Portal registrierten Chipkarten eine ausgewählt und die Fahrkarten zu dieser Chipkarte sollen angezeigt werden. Anmerkung: Ob der Kunde die Anzeige der Daten per Klick anfordert oder ob ihm alle Daten sofort nach dem Login angezeigt werden oder eine beliebige andere Gestaltung gewählt wird, soll durch dieses Dokument nicht vorgegeben werden. Das Kundenportal fordert die Fahrkartendaten zu der Chipkarte bei seinem Heimat-HGS an.

3 Zur Codierung der KA-Datenstrukturen in der Bidirektionalen Schnittstelle für Vertrieb & Service, siehe Kap. 5.1.5. 4 Wenn die Produktion der Ersatzchipkarte über den Massenpersonalisierer erfolgen muss und vorhersehbar länger dauert als man dem Kunden zumuten will.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 13 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 74]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

Das Heimat-HGS ermittelt die im Heimat-HGS verwalteten Fahrkarten zu der Chipkarte und ruft über die Vermittlungsstelle alle anderen Hintergrundsysteme auf, die Daten für die von ihnen verwalteten Fahrkarten zu der Chipkarte zu liefern. Diese Funktion wird von der Vermittlungsstelle in der Form bereitgestellt, dass die Aufrufe parallel abgesetzt werden und die Teilergebnisse in einem Gesamtergebnis an den Aufrufer zurückgeliefert werden (Split/Join). Hierbei gilt die Regel, dass nicht innerhalb des vereinbarten Zeitfensters (Timeout) antwortende Systeme übergangen werden und nicht zum Abbruch der Aktion führen. Die Vermittlungsstelle liefert dem anfragenden Hintergrundsystem neben der Liste der Fahrkartendaten auch eine Liste der Hintergrundsysteme, die nicht geantwortet haben. [Schnittstellenfunktion 5.3.1 ermittleTicketDatenFuerChipkarte] Sofern ein oder mehrere Hintergrundsysteme nicht geantwortet haben, soll das Heimat-HGS keine Wiederholungsversuche durchführen. Die ermittelten Fahrkartendaten werden vom Heimat-HGS an das Kundenportal übergeben. Sofern ein oder mehrere Hintergrundsysteme nicht geantwortet haben, ist diese Information ebenfalls an das Kundenportal zu übergeben, so dass dem Nutzer ein entsprechender Hinweis angezeigt werden kann. Für die dem Kunden mindestens zu einer Fahrkarte im Kundenportal anzuzeigenden Daten sind die Festlegungen im [FK_BD-SST] zu beachten.

3.2.4 Anzeige der Berechtigungsnachweise zu einer Chipkarte [kein Anwendungsfall für bidirektionale SST]

Für die Ermittlung der Daten der Berechtigungsnachweise im Kundenportal wird keine Funktion in der bidirektionalen Schnittstelle benötigt. Die Daten über die Berechtigungsnachweise (Kundendaten auf dem NM) werden in dem Hintergrundsystem verwaltet, in dem auch die Chipkarte verwaltet wird. Dies ist gleichzeitig immer das Heimat-HGS, in dem der Kunde seine Chipkarte registrieren kann. Für die dem Kunden mindestens zu einem Berechtigungsnachweis im Kundenportal anzuzeigenden Daten sind die Festlegungen im [FK_BD-SST] zu beachten.

3.2.5 Verkauf von Barfahrkarten auf fremde Chipkarten Anforderung aus dem Fachkonzept: Über den RMV-TicketShop sowie die WebShops der externen Mandanten muss der Vertrieb von Barfahrkarten sowohl auf eigener als auch auf fremder Chipkarte (in Stufe 1 nur eTicket RheinMain-Chipkarten) ermöglicht werden. Der Nutzer hat sich am Portal angemeldet und will eine Barfahrkarte für eine vorhandene, nicht für den Nutzer in dem Portal registrierte Chipkarte erwerben. Dazu gibt er in dem Portal die Chipkartennummer ein. Das Portal prüft anhand der Luhn-Prüfziffer die Plausibilität der eingegebenen Chipkartennummer5. In Stufe 1 prüft das Portal auch, dass die Chipkartennummer mit der Org-Id des RMV beginnt. Das Portal übergibt die erfasste Chipkartennummer zur weiteren Prüfung an das Heimat-HGS des Portals. Das Heimat-HGS prüft, ob die Chipkartennummer sich auf eine vom Heimat-HGS verwaltete Chipkarte bezieht. Falls dies der Fall ist, ermittelt das Heimat-HGS die benötigten Daten

5 Zur Luhn-Prüfziffer siehe auch KA-Spezifikation HD-BOM. Für eTicket RheinMain Chipkarten wird das Format verwendet, bei dem die Nutzermedium-ID der NmAppInstanz-ID entspricht. Die Luhn-Prüfziffer ist dabei die letzte Stelle der NmAppInstanz-ID.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 14 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 75]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

(NmAppInstanzId, NmApp.Gültig-ab, NmApp.Gültig-bis, NmApp.Status, Liste mit Berechtigungsnachweisen) und übergibt sie dem Kundenportal. Falls die Chipkartennummer sich nicht auf eine vom Heimat-HGS verwaltete Chipkarte bezieht, ruft das Heimat-HGS über die Vermittlungsstelle alle anderen Hintergrundsysteme auf, die benötigten Daten zu liefern. Diese Funktion wird von der Vermittlungsstelle in der Form bereitgestellt, dass die Aufrufe parallel abgesetzt werden und die Teilergebnisse in einem Gesamtergebnis an den Aufrufer zurückgeliefert werden (Split/Join). Hierbei gilt die Regel, dass nicht innerhalb des vereinbarten Zeitfensters (Timeout) antwortende Systeme übergangen werden und nicht zum Abbruch der Aktion führen. Die Vermittlungsstelle liefert dem anfragenden Hintergrundsystem neben dem Ergebnis der Datenermittlung auch eine Liste der Hintergrundsysteme, die nicht geantwortet haben. [Schnittstellenfunktion 5.3.2 ermittleChipkartenDaten]

Da in diesem Fall die benötigten Daten von genau einem Hintergrundsystem verwaltet werden, ist das Ausbleiben von Hintergrundsystem-Antworten unerheblich, wenn die benötigten Daten ermittelt werden konnten. Sofern die Datenermittlung kein Ergebnis erbracht hat und ein oder mehrere Hintergrundsysteme nicht geantwortet haben, soll das Heimat-HGS keine Wiederholungsversuche durchführen, sondern dem Kundenportal die Information übergeben, dass keine Daten ermittelt werden konnten und nicht alle Systeme geantwortet haben, so dass dem Nutzer ein entsprechender Hinweis angezeigt werden kann. Sofern alle Systeme geantwortet haben, aber keines der Systeme die gesuchte Chipkarte verwaltet, ist diese Information an das Kundenportal zurückzugeben, wo der Vorgang mit einer Fehlermeldung („Unbekannte Chipkarte“) für den Nutzer abgebrochen werden muss. Sofern die benötigten Daten (NmAppInstanzId, NmApp.Gültig-ab, NmApp.Gültig-bis, NmApp.Status, Liste mit Berechtigungsnachweisen, Org-Id des chipkartenverwaltenden VU) ermittelt werden konnten, werden die Daten vom Heimat-HGS an das Kundenportal übergeben. Ein Verkauf auf diese Chipkarte ist nur zulässig, wenn der NmApp.Status „OK“ ist. Der Kunde wählt das Produkt aus, dass er erwerben möchte. Dabei sollte das Kundenportal die erhaltenen Daten NmApp.Gültig-ab, NmApp.Gültig-bis sowie die Berechtigungsnachweise verwenden um die Produktauswahl zu steuern. Die Bestellung wird vom Portal an dessen Heimat-HGS übergeben. Das Heimat-HGS prüft die bestellte Fahrkarte gegen die Chipkartendaten (NmApp.Gültig-ab, NmApp.Gültig-bis, NmApp.Status, Liste mit Berechtigungsnachweisen). Sofern auch alle weiteren Prüfungen (Gegenstand interner Festlegungen des Unternehmens, das das Heimat- HGS betreibt) erfolgreich sind, wird die erworbene Fahrkarte von dem Heimat-HGS ausgeliefert (z.B. per Aktionsliste).

3.2.6 Erfassung und Ausgabe von Berechtigungsnachweisen [kein Anwendungsfall]

Die Erfassung von Berechtigungsnachweisen (z.B. Altersnachweis für eine Schülerfahrkarte) ist im Internetvertrieb nicht vorgesehen, da die Prüfung des Anspruchs anhand von hochgeladenen Dokumenten als problematisch angesehen wird.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 15 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 76]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

4 Schnittstelle Service durch Dritte (personalbedient)

4.1 Allgemein

Zur systemübergreifenden Abwicklung von Servicefällen des Service durch Dritte implementieren die Hintergrundsysteme geeignete Webservices, die sich an die Webservices für den Internetvertrieb anlehnen (Nutzung von Synergien), siehe Kapitel 3. Der Umfang der im Service durch Dritte angebotenen Services ist jedoch nicht identisch mit den im Internetvertrieb angebotenen Services, so dass einerseits zusätzliche Webservices benötigt werden und andererseits einige für den Internetvertrieb angebotene Webservices im Service durch Dritte nicht genutzt werden dürfen. Anders als beim Internetvertrieb erfolgt im Service durch Dritte keine Autorisierung des Datenzugriffs durch den Kunden durch Anmeldung im Internetportal. Die Autorisierung erfolgt durch Einlesen der Chipkarte oder Angabe persönlicher Daten bzw. Vorlage geeigneter Dokumente. Die Sicherstellung einer ausreichenden Autorisierung erfolgt letztlich durch den Mitarbeiter des Verkehrsunternehmens entsprechend den zwischen den Verkehrsunternehmen und dem Datenschutzbeauftragten abgestimmten Vorgaben.6 Seitens der technischen Systeme sind insbesondere die mit dem Datenschutz abgestimmten Beschränkungen bei der Suche und der Anzeige von Kundendaten zu beachten.7 Ein weiterer Unterschied zum Internetvertrieb besteht darin, dass Änderungen auf der Chipkarte unverzüglich ausgeführt werden können (und auch sollen). Bei der technischen Gestaltung ist dabei auch zu berücksichtigen, dass die Ausführung der Chipkartentransaktion auch scheitern kann. Durch einen solchen Transaktionsabbruch dürfen keine irreparablen Zustände (inkonsistente Daten) entstehen.

4.2 Anwendungsfälle für den Service durch Dritte

Der Servicekatalog für den Service durch Dritte ist im Fachkonzept [FK-BD-SST] festgelegt. Nachfolgend wird die Umsetzung der dort aufgeführten Servicefälle (=Anwendungsfälle) beschrieben.

4.2.1 Bestellung Ersatzchipkarte

Siehe Kapitel 3.2.2. Im Unterschied zu Kapitel 3.2.2 kann es im Service durch Dritte vorkommen, dass die zu ersetzende Chipkarte nicht im Heimat-HGS der Kundenservicestelle verwaltet wird. In diesem Fall ist zunächst eine systemübergreifende Suche der zu ersetzenden Chipkarte erforderlich.

6 Als Grundlage wird auch eine geeignete vertragliche Regelung zwischen den beteiligten Verkehrsunternehmen benötigt. Für die technische Spezifikation wird davon ausgegangen, dass eine solche vertragliche Regelung existiert bzw. rechtzeitig hergestellt wird. 7 Als Grundlage für die diesbezüglichen Festlegungen in dieser Spezifikation werden die mit dem Datenschutz für den mandantenübergreifendem Datenzugriff im vHGS abgestimmten Regelungen verwendet.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 16 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 77]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

Die systemübergreifende Chipkartensuche erfolgt über einen der folgenden Wege:

 Suche nach Chipkartennummer (auf Chipkarte aufgedruckt bzw. im Kundenbeleg angegeben)

 Suche nach Chipkarteninhaber Bei bekannter Chipkartennummer werden analog zu der Datenermittlung in Kapitel 3.2.5 über die Vermittlungsstelle alle Hintergrundsysteme abgefragt. [Schnittstellenfunktion 5.3.2 ermittleChipkartenDaten] Bei einer Suche über die Chipkartennummer sollte die eingegebene Chipkartennummer von der Verkaufsstellensoftware (oder dem Heimat-HGS der Kundenservicestelle) anhand der Luhn- Prüfziffer auf Plausibilität geprüft werden8. Weiterhin sollte geprüft werden, dass die Chipkartennummer mit der Org-Id des RMV beginnt. Bei einer Suche über den Chipkarteninhaber muss der vollständige Nachname eingegeben werden und es wird nach exakten Treffern für den eingegebenen Nachnamen gesucht. Für den Vornamen muss mindestens der Anfangsbuchstabe eingegeben werden und es wird nach „beginnt mit“ gesucht. Für die gefundenen Kandidaten werden Geburtsdatum (nur Monat und Jahr) und Postleitzahl angezeigt sowie die Chipkartennummer. [Schnittstellenfunktion 5.3.3 findeChipkarteFuerNutzer] Damit sich der Mitarbeiter einen Überblick über die auf der Chipkarte vorhandenen Fahrkarten verschaffen kann, können für eine Chipkarte analog zu Kapitel 3.2.3 die Fahrkartendaten von allen Hintergrundsystemen über die Vermittlungsstelle abgefragt werden. [Schnittstellenfunktion 5.3.1 ermittleTicketDatenFuerChipkarte]Das Ergebnis der Datenermittlung wird dem Mitarbeiter angezeigt. Der Mitarbeiter löst die Ersatzkartenbestellung aus. Der Gültigkeitsstart der Ersatzchipkarte und der Ersatzfahrkarten wird dabei auf den 1. des aktuellen Monats festgelegt, d.h. die Ersatzchipkarte ist sofort gültig und die ersetzte Chipkarte wird sofort gesperrt. Sofern die zu ersetzende Chipkarte nicht von dem Heimat-HGS der Kundenservicestelle verwaltet wird, wird über die Vermittlungsstelle von dem Hintergrundsystem des Verkehrsunternehmens, das die zu ersetzende Chipkarte ausgegeben hat, ein Chipkartenausgabeauftrag einschließlich der Berechtigungsnachweise und der PIN/PUK (TXAGBBER, TXAGBKUNDE, TXAGBPINPUC) angefordert. [Schnittstellenfunktion 5.3.6 liefereErsatzChipkarteAusgabe]

Analog zu Kapitel 3.2.2 werden die Ausgabeaufträge für die auf die Ersatzchipkarte auszugebenden Fahrkarten über die Vermittlungsstelle von den anderen Hintergrundsystemen angefordert. [Schnittstellenfunktion 5.3.4 liefereTicketsFuerErsatzChipkarte]

Die Ersatzchipkarte wird nach Möglichkeit sofort in der Kundenservicestelle ausgestellt und dem Kunden übergeben. Die Ersatzchipkarte wird nicht bedruckt, so dass für die Ausgabe ein Chipkartenterminal ausreichend ist. Dem Kunden werden außerdem die Ausgabedokumente zur Ersatzchipkarte ausgedruckt und übergeben. Darin befindet sich der Code zur Registrierung der Chipkarte im Internetportal des Heimat-HGS der Chipkarte. Nach erfolgter Erstellung der Ersatzchipkarte übergibt das Heimat-HGS der Kundenservicestelle über die Vermittlungsstelle

8 Zur Luhn-Prüfziffer siehe Fußnote in Kapitel 3.2.5.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 17 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 78]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

 … dem Hintergrundsystem des Verkehrsunternehmens, das die zu ersetzende Chipkarte ausgegeben hat, die Verwaltung der ausgegebenen Ersatzchipkarte (Daten: Chipkartennummer, TXAA, Registrierungscode); [Schnittstellenfunktion 5.3.7 ersatzChipkarteAusgegeben]

Das abgebende HGS muss die Chipkarte in seinem Datenbestand entsprechend kennzeichnen. Das aufnehmende HGS muss die Chipkarte in seinem HGS anlegen und entsprechend (als fremd ausgegebene Ersatzchipkarte) kennzeichnen; den Registrierungscode zu der Chipkarte speichern; den TXAA als KVPS verarbeiten und an das AHS senden.

 … dem vHGS (Chipkartenverwaltung des RMV) die Information, dass die Chipkarte als Ersatzchipkarte für ein anderes VU ausgegeben wurde (Daten: Chipkartennummer, NmAppInstanzId; Org-Id aufnehmenden VU); [Schnittstellenfunktion 5.3.8 zustaendigkeitFuerChipkarteUebergeben]

Das vHGS pflegt die Nummernkreise der Chipkartenverwaltung entsprechend und wird den auf dem „normalen Weg“ (von dem aufnehmenden VU) eintreffenden TXAA nicht als Nummernkreisverletzung monieren.

 … die Transaktionsnachweise (TXABER) aus der Ausgabe von Fahrkarten der fremden Hintergrundsysteme an die jeweiligen Hintergrundsysteme, vgl. Kapitel 3.2.2. [Schnittstellenfunktion 5.3.5 ticketAusgegebenAufErsatzChipkarte]

4.2.2 Erfassung und Ausgabe von Berechtigungsnachweisen

Hinweis: Zur Verwendung der Datenstruktur „Kundendaten auf dem NM“ und Berechtigungsnachweisen im eTicket RheinMain siehe [SPEC-KDNM]. Der Kunde wünscht die Ausstellung eines Berechtigungsnachweises, den das Verkehrsunternehmen, das die Kundenservicestelle betreibt ausstellen kann9. Dies kann auch im Rahmen eines Verkaufsvorgangs für ein Produkt, das den Berechtigungsnachweis erfordert, geschehen. Die auf der Chipkarte des Kunden gespeicherten „Kundendaten auf dem NM“ werden von der Chipkarte gelesen. Sofern die Chipkarte des Kunden von dem Heimat-HGS der Kundenservicestelle verwaltet wird, werden in der Kundenservicestelle die erforderlichen Daten erfasst und der Berechtigungsnachweis wird ausgegeben. Die bidirektionale Schnittstelle wird in diesem Fall nicht benötigt. Sofern die Chipkarte des Kunden nicht von dem Heimat-HGS der Kundenservicestelle verwaltet wird, sind folgende Fälle zu unterscheiden:

1. Die Datenstruktur „Kundendaten auf dem NM“ auf der Chipkarte des Kunden enthält noch keine Daten, insbesondere auch noch nicht die „Stammdaten“ kundeGeburtsdatum, kundeSprache.code, kundeName, kundeVorname, kundeGeschlecht.code.

9 Neben den „RMV-weiten“ Berechtigungsnachweisen (z.B. 65+ oder Schüler bzw. Azubi) gibt es auch lokale Berechtigungsnachweise (z.B. Sozialpässe der Kommunen), die nur von wenigen (in der Regel lokal ansässigen) Verkehrsunternehmen ausgestellt werden, die auch mit der Prüfung der zugehörigen Dokumente vertraut sind.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 18 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 79]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

2. Die Datenstruktur „Kundendaten auf dem NM“ auf der Chipkarte des Kunden enthält bereits mindestens die „Stammdaten“. Für den Fall (1): Das Heimat-HGS der Kundenservicestelle fordert über die Vermittlungsstelle die bei dem Verkehrsunternehmen, das die Chipkarte ausgegeben hat, ggf. bereits bekannten „Stammdaten“ über den Chipkarteninhaber an. [Schnittstellenfunktion 5.3.9 ermittleBerNwKundendatenFuerCk]

Sofern die Abfrage kein Ergebnis ergibt und mindestens ein HGS nicht geantwortet hat, wird dies dem Mitarbeiter angezeigt und der Mitarbeiter hat die Möglichkeit, die Abfrage zu wiederholen. Das Ergebnis der Abfrage wird dem Mitarbeiter angezeigt und der Mitarbeiter prüft die Übereinstimmung mit den Daten, die der Kunde für den gewünschten Berechtigungsnachweis angegeben hat. Falls die Daten nicht übereinstimmen, bricht der Mitarbeiter den Vorgang ab. Andernfalls übernimmt der Mitarbeiter die von dem Verkehrsunternehmen, das die Chipkarte ausgegeben hat, gelieferten Daten und ergänzt ggf. fehlende „Stammdaten“. Sofern bei dem Verkehrsunternehmen, das die Chipkarte ausgegeben hat, noch keine Daten zum Chipkarteninhaber bekannt waren, erfasst der Mitarbeiter die „Stammdaten“. Das Heimat-HGS der Kundenservicestelle teilt dem Heimat-HGS der Chipkarte über die Vermittlungsstelle die erfassten bzw. ergänzten „Stammdaten“ mit. [Schnittstellenfunktion 5.3.10 aktualisiereBerNwKundendaten] Das Heimat-HGS aktualisiert den Datensatz des Chipkarteninhabers bzw. legt diesen an. Weiterer Ablauf: siehe Fall (2). Für den Fall (2): Der Mitarbeiter erfasst die Daten für den spezifischen Berechtigungsnachweis (kundenTyp*.code, …, kundenTyp*.StreckeNach) und ggf. ein Dokument, das den Anspruch auf den Berechtigungsnachweis begründet.. Dabei sind die Regelungen der [SPEC-KDNM] zu beachten. Der Berechtigungsnachweis wird auf die Chipkarte geschrieben. Technisch bedingt kann auf der Chipkarte die Datenstruktur „Kundendaten auf dem NM“ nur komplett überschrieben werden. Dabei werden auch die ggf. im Fall (1) ermittelten „Stammdaten“ in die Datenstruktur „Kundendaten auf dem NM“ geschrieben. Das Heimat-HGS der Kundenservicestelle teilt dem Heimat-HGS der Chipkarte über die Vermittlungsstelle die Aktualisierung der Datenstruktur „Kundendaten auf dem NM“ mit und übergibt dabei ggf. auch das Dokument, das als Grundlage für den Berechtigungsnachweis erfasst wurde. [Schnittstellenfunktion 5.3.11 berechtigungsnachweisAusgegeben] Das Heimat-HGS der Chipkarte aktualisiert den eigenen Datenbestand.

4.2.3 Anzeige aller Fahrkarten zu einer Chipkarte Siehe Kapitel 3.2.3.

4.2.4 Prüfung auf gültige Fahrkarte für die Erstattung von Ersatzfahrkarten

Die Prüfung erfolgt vom Mitarbeiter anhand der „Anzeige aller Fahrkarten zu einer Chipkarte“ (siehe Kapitel 4.2.3).

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 19 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 80]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

4.2.5 Prüfung auf gültige Fahrkarte für die Klärung eines EBE-Falles

Die Prüfung erfolgt vom Mitarbeiter anhand der „Anzeige aller Fahrkarten zu einer Chipkarte“ (siehe Kapitel 4.2.3).

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 20 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 81]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

5 Schnittstellenfunktionen und Datenstrukturen

5.1 Allgemeine Festlegungen

5.1.1 SOAP-Webservices

Die Schnittstellenfunktionen werden als SOAP-Webservice-Methoden nach WS-Standard definiert. Die in [SST-ExtM-BD_HD], Kap. 4 festgelegten allgemeinen technischen Eigenschaften sind zu beachten. Die Beschreibungen in den nachfolgenden Abschnitten dienen als Referenz und Vorgabe für die Erstellung einer formalen Spezifikation in Form einer WSDL/XSD. Die WSDL/XSD wird am Beginn der Implementierung von Cubic erstellt.

5.1.2 Timeouts

Der Aufruf erfolgt synchron, der Aufrufer wartet so lange bis eine Antwort erfolgt oder eine Zeitüberschreitung eintritt. Siehe auch Vorgaben zum Zeitverhalten in Kap. 4.5 des Dokuments [SST-ExtM-BD-HD]. Tritt die Zeitüberschreitung während eines von der Vermittlungsstelle initiierten parallelen Aufrufs an alle Hintergrundsysteme auf, fährt die Vermittlungsstelle fort, fasst alle anderen Ergebnisse zusammen und fügt eine Zusatzinformation für den Aufrufer hinzu, welche der angefragten Hintergrundsysteme nicht geantwortet haben. Damit dieses Vorgehen funktioniert, muss die Wartezeit des Hintergrundsystems, das die Vermittlungsstelle aufgerufen hat, länger sein als die Wartezeit der Vermittlungsstelle bei der Abfrage der Hintergrundsysteme (Beispiel: HGS-1 ruft die Vermittlungsstelle; Vermittlungsstelle ruft die HGS-2, -3 und -4; die Vermittlungsstelle wartet max. 8 Sekunden auf die Antworten von HGS-2, -3 und -4; HGS wartet max. 10 Sekunden auf die Antwort der Vermittlungsstelle). Die anzuwendenen Wartezeiten sind in den Hintergrundsystemen und der Vermittlungsstelle jeweils als Konfigurationsparameter zu implementieren. Die initial einzustellenden Werte werden vor der Inbetriebnahme abgestimmt und ggf. später anhand der Betriebserfahrungen neu abgestimmt und angepasst.

5.1.3 SOAP-Fault

Bei jedem Funktionsaufruf kann an Stelle der Antwort ein Fehler (SOAP Fault) zurückgeliefert werden. Dieser enthält einen Fehlercode und eine Fehlernachricht. Das aufrufende System muss mindestens in der Lage sein, nach Erhalt eines SOAP-Fault den Vorgang geordnet abzubrechen. Abhängig vom jeweiligen Anwendungsfall, kann das aufrufende System den Vorgang ggf. auch mit den vorhandenen Informationen weiterführen oder Wiederholungsversuche durchführen, siehe Anwendungsfallbeschreibungen in Kap. 3.2 und 4.2.

5.1.4 Identifikatoren (IDs) Jede der Schnittstellenfunktionen enthält als Parameter die Kennung des Hintergrundsystems (system_id) und eine Kennung des internetbasierten Kundenportals (portal_id) bzw. Arbeitsplatzkennung (arbeitsplatz_id), von dem der Funktionsaufruf ausgeht.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 21 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 82]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

Jede der Schnittstellenfunktionen enthält als Parameter die Kennung des adressierten Hintergrundsystems (system_id). In den Fällen, in denen das zu adressierende HGS nicht bekannt ist, wird der Parameter leer gelassen. Die System-IDs werden durch den Betreiber der Vermittlungsstelle festgelegt. Soweit nichts anderes definiert ist, wird als System-ID die KA Org-ID des Verkehrsunternehmens bzw. beim vHGS die KA Org-ID des RMV verwendet. Die Portal-IDs bestehen aus der System-ID des Heimat-HGS des Portals + vom Betreiber des Heimat-HGS festgelegte, im Kontext der System-ID eindeutige Kennung. Die Arbeitsplatz-IDs bestehen aus der ID des Verkehrsunternehmens + eindeutige Kennung innerhalb des Verkehrsunternehmens. Als ID des Verkehrsunternehmens wird die KA Org-ID verwendet.

5.1.5 KA-Datenstrukturen

Die in den Schnittstellenfunktionen verwendeten KA-Datenstrukturen werden auf Basis der [KA_SPEC] in deren Version 1.3.0 spezifiziert. Es werden keine KA-XSDs eingebunden, sondern die Datenstrukturen/Attribute werden in der XSD der Bidirektionalen Schnittstelle für Vertrieb & Service definiert. Diese Vorgehensweise bringt folgende Vorteile:

 keine technische Abhängigkeit zu KA-Releasewechseln,

 Vermeidung überflüssiger (in der SST nicht genutzter) Datenstrukturen,

 Definition von XML-Datenstrukturen für Auftragsdaten der KA Spec-PE. Für die Implementierung der Bidirektionalen Schnittstelle für Vertrieb & Service gelten ausschließlich die Datenstrukturen wie sie in diesem Dokument beschrieben und in der XSD der Bidirektionalen Schnittstelle für Vertrieb & Service festgelegt werden.

5.2 Mehrfach verwendbare Datenstrukturen

5.2.1 AnfrageQuelle

10 „erf.“ = erforderlich = Attribut muss gefüllt sein. 11 „opt.“ = optional = Attribut muss nicht gefüllt sein

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 22 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 83]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

5.2.2 Adresse

5.2.3 TicketDaten

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 23 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 84]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

5.2.4 KundendatenNm

Zur Kodierung der Attribute und Verwendung im eTicket RheinMain siehe [SPEC-KDNM].

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 24 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 85]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

5.2.5 TXAGBBER_Auftrag_Ber Ausgabeauftrag für eine Berechtigung. Die Attribute sind in Anlehnung an die [KA_SPEC_PE] definiert. Attribute aus der [KA_SPEC_PE], die nur der Steuerung der PE-Sessions dienen, wurden weggelassen.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 25 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 86]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

5.2.6 TXABER_Daten Daten der Ausgabetransaktion einer Berechtigung. Die Datenstruktur entspricht dem TXABER der [KA_SPEC] ohne TX_BASE, mit explizit angegebener Berechtigung-ID (redundant zu der Angabe im ByteArray der Nm-Transaktion).

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 26 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 87]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

5.2.7 TXAGBBER_Auftrag_App

Ausgabeauftrag für eine Nutzermediumapplikation. Die Attribute sind in Anlehnung an die [KA_SPEC_PE] definiert. Attribute aus der [KA_SPEC_PE], die nur der Steuerung der PE- Sessions dienen, wurden weggelassen.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 27 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 88]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

5.2.8 TXAGBKUNDE_Auftrag

Ausgabeauftrag für das Schreiben der Kundendaten auf das Nutzermedium (Ausgabe der Datenstruktur KundenProfil_OePVApplikation). Die Attribute sind in Anlehnung an die [KA_SPEC_PE] definiert. Attribute aus der [KA_SPEC_PE], die nur der Steuerung der PE- Sessions dienen, wurden weggelassen.

5.2.9 TXAGBPINPUC_Auftrag

Ausgabeauftrag für das Setzen der PIN und PUK in der Nutzermediumapplikation. Die Attribute sind in Anlehnung an die [KA_SPEC_PE] definiert. Attribute aus der [KA_SPEC_PE], die nur der Steuerung der PE-Sessions dienen, wurden weggelassen.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 28 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 89]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

5.2.10 TXAA_Daten

Daten der Ausgabetransaktion einer Nutzmediumapplikationsinstanz. Die Datenstruktur entspricht dem TXAA der [KA_SPEC] ohne TX_BASE.

5.3 Schnittstellenfunktionen

5.3.1 ermittleTicketDatenFuerChipkarte ErmittleTicketDatenFuerCkAntwort ermittleTicketDatenFuerChipkarte ( ErmittleTicketDatenFuerCkAnfrage ) Zweck: Ermittlung von Fahrkartendaten zu der Chipkarte mit der Chipkartennummer ckNr. Wird verwendet von:

 Internetvertrieb

 3.2.3 Anzeige aller Fahrkarten zu einer Chipkarte

 Service durch Dritte

 4.2.1 Bestellung Ersatzchipkarte

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 29 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 90]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

 4.2.3 Anzeige aller Fahrkarten zu einer Chipkarte

 4.2.4 Prüfung auf gültige Fahrkarte für die Erstattung von Ersatzfahrkarten

 4.2.5 Prüfung auf gültige Fahrkarte für die Klärung eines EBE-Falles Aufrufparameter

Rückgabewert

5.3.2 ermittleChipkartenDaten

ErmittleCkDatenAntwort ermittleChipkartenDaten( ErmittleCkDatenAnfrage ) Zweck: Ermittlung von Daten zu der Chipkarte mit der Chipkartennummer ckNr.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 30 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 91]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

Wird verwendet von:

 Internetvertrieb

 3.2.5 Verkauf von Barfahrkarten auf fremde Chipkarten

 Service durch Dritte

 4.2.1 Bestellung Ersatzchipkarte Aufrufparameter

Rückgabewert

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 31 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 92]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

5.3.3 findeChipkarteFuerNutzer

FindeCkFuerNutzerAntwort findeChipkarteFuerNutzer ( FindeCkFuerNutzerAnfrage ) Zweck: Ermittlung der Chipkartennummer anhand des Namens des Chipkarteninhabers. Die Funktion liefert ggf. mehrere Kandidaten. Wird verwendet von:

 Internetvertrieb

 Nicht verwendet

 Service durch Dritte

 4.2.1 Bestellung Ersatzchipkarte Aufrufparameter

Rückgabewert

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 32 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 93]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

5.3.4 liefereTicketsFuerErsatzChipkarte LiefereTicketsFuerErsatzCkAntwort liefereTicketsFuerErsatzChipkarte ( LiefereTicketsFuerErsatzCkAnfrage ) Zweck: Fordert KA-Berechtigung-Ausgabeaufträge für das Neuausfertigen von Fahrkarten auf einer Ersatzchipkarte an. Wird verwendet von:

 Internetvertrieb

 3.2.2 Bestellung Ersatzchipkarte

 Service durch Dritte

 4.2.1 Bestellung Ersatzchipkarte Aufrufparameter

Rückgabewert

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 33 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 94]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

eine leere Liste.

5.3.5 ticketAusgegebenAufErsatzChipkarte

ticketAusgegebenAufErsatzChipkarte ( TicketAusgegebenAufErsatzCkDaten ) Zweck: Übergabe der Daten über die Neuausfertigung einer Fahrkarte (=Ausgabe einer KA- Berechtigung) auf einer Ersatzchipkarte an das Verkehrsunternehmen, das die Fahrkarte verwaltet. Wird verwendet von:

 Internetvertrieb

 3.2.2 Bestellung Ersatzchipkarte

 Service durch Dritte

 4.2.1 Bestellung Ersatzchipkarte Aufrufparameter

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 34 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 95]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

Rückgabewert Kein fachlicher Rückgabewert.

5.3.6 liefereErsatzChipkarteAusgabe LiefereErsatzCkAusgabeAntwort liefereErsatzChipkarteAusgabe ( LiefereErsatzCkAusgabeAnfrage ) Zweck: Fordert KA-Ausgabeaufträge für das Ausgeben einer Ersatzchipkarte an. Wird verwendet von:

 Internetvertrieb

 Keine Verwendung

 Service durch Dritte

 4.2.1 Bestellung Ersatzchipkarte Aufrufparameter

Rückgabewert

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 35 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 96]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

5.3.7 ersatzChipkarteAusgegeben ersatzChipkarteAusgegeben (ReplacementCardData ) Zweck: Übergabe der Daten über die Ausgabe einer Ersatzchipkarte vom ausführenden Verkehrsunternehmen an das Verkehrsunternehmen, das die ersetzte Chipkarte verwaltet und künftig auch die Ersatzchipkarte verwalten soll. Wird verwendet von:

 Internetvertrieb

 Keine Verwendung

 Service durch Dritte

 4.2.1 Bestellung Ersatzchipkarte Aufrufparameter

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 36 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 97]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

Rückgabewert Kein fachlicher Rückgabewert.

5.3.8 zustaendigkeitFuerChipkarteUebergeben

zustaendigkeitFuerChipkarteUebergeben (ZustaendigkeitFuerCkUebergebenDaten ) Zweck: Mitteilung über die Übergabe der Verantwortung für eine Chipkarte an ein anderes Verkehrsunternehmen. Die Mitteilung erfolgt insbesondere nach Ausgabe einer Ersatzchipkarte im systemübergreifenden Kundenservice. Die Mitteilung geht immer an den RMV im vHGS zur Pflege der Chipkartennummernkreise. Wird verwendet von:

 Internetvertrieb

 Keine Verwendung

 Service durch Dritte

 4.2.1 Bestellung Ersatzchipkarte Aufrufparameter

Rückgabewert Kein fachlicher Rückgabewert.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 37 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 98]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

5.3.9 ermittleBerNwKundendatenFuerCk ErmittleBerNwKdFuerCkAntwort ermittleBerNwKundendatenFuerCk ( ErmittleBerNwKdFuerCkAnfrage ) Zweck: Ermittlung von Stammdaten des Chipkarteninhabers der Chipkarte mit der Chipkartennummer ckNr für die Kundendaten auf dem Nutzermedium für die Ausgabe eines Berechtigungsnachweises. Wird verwendet von:

 Internetvertrieb

 Keine Verwendung

 Service durch Dritte

 4.2.2 Erfassung und Ausgabe von Berechtigungsnachweisen Aufrufparameter

Rückgabewert

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 38 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 99]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

(s. 5.2.3) Kundendaten auf dem NM. Alle Attribute innerhalb der Struktur optional, da auch im Datenbestand des VU, das die Chipkarte ausgegeben hat, ggf. noch nicht bekannt.

5.3.10 aktualisiereBerNwKundendaten

aktualisiereBerNwKundendaten ( AktualisiereBerNwKdDaten ) Zweck: Übermittlung von neu erfassten Stammdaten des Chipkarteninhabers für die Kundendaten auf dem Nutzermedium an das Hintergrundsystem, in dem die Chipkarte verwaltet wird. Wird verwendet von:

 Internetvertrieb

 Keine Verwendung

 Service durch Dritte

 4.2.2 Erfassung und Ausgabe von Berechtigungsnachweisen Aufrufparameter

Rückgabewert Kein fachlicher Rückgabewert.

5.3.11 berechtigungsnachweisAusgegeben berechtigungsnachweisAusgegeben (BerNwAusgegebenDaten) Zweck:

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 39 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 100]

eTicket RheinMain Schnittstellenspezifikation - vHGS / Externe Mandanten - Vertrieb & Service

Übergabe der Daten über die Ausgabe eines Berechtigungsnachweises an das Verkehrsunternehmen, das die Chipkarte verwaltet und damit auch die Daten zum Chipkarteninhaber und dessen Berechtigungsnachweisen führt. Wird verwendet von:

 Internetvertrieb

 Keine Verwendung

 Service durch Dritte

 4.2.2 Erfassung und Ausgabe von Berechtigungsnachweisen Aufrufparameter

Rückgabewert Kein fachlicher Rückgabewert.

Dok-Ref.: SST_ExtM-BD_VS Version: 2.4 Datum: 14.09.2018 Seite 40 Datei: SST-Spez_Ext-Mandant-Bidirektional_VS_v2.4 Cubic Transportation Systems (Deutschland) GmbH

[Seite 102]

Teilnehmer am vHGS

Liste mit allen Teilnehmern am vHGS

nach Aufgabenbereich

Anlage 4 zum vHGS-Vertrag

[Seite 103]

Versionsverwaltung

21-10-01 Anlage 4 zum vHGS-Vertrag Teilnehmer Seite 2 von 10

[Seite 104]

Inhaltsverzeichnis Seite

1 Interne Mandanten .................................................................................... 4 1.1 Kundenvertragspartner ............................................................................... 4 1.2 Kundenvertragspartner mit eigenem Vertriebsdienstleister ........................ 7 1.3 Dienstleister ................................................................................................ 8

2 Externe Mandanten ................................................................................ 10

21-10-01 Anlage 4 zum vHGS-Vertrag Teilnehmer Seite 3 von 10

[Seite 105]

Folgende Teilnehmer nehmen am vHGS teil und nehmen folgende Aufgabenberei- che wahr:

1 Interne Mandanten

1.1 Kundenvertragspartner

Folgende Teilnehmer treten primär in der KA-Rolle als Kundenvertragspartner (KVP) auf, die darüber hinaus ebenfalls den Aufgabenbereich Kontrolle wahrnehmen können – der Aufgabenbereich Kontrolle ist der KA-Rolle Dienstleister (DL) zugeordnet (Ein Teilnehmer kann also sowohl die Rolle des KVP als auch des DL einnehmen):

21-10-01 Anlage 4 zum vHGS-Vertrag Teilnehmer Seite 4 von 10

[Seite 106]

21-10-01 Anlage 4 zum vHGS-Vertrag Teilnehmer Seite 5 von 10

[Seite 107]

21-10-01 Anlage 4 zum vHGS-Vertrag Teilnehmer Seite 6 von 10

[Seite 108]

• inkl. Service durch Dritte ° ohne Service durch Dritte

1.2 Kundenvertragspartner mit eigenem Vertriebsdienstleister

Folgende Teilnehmer setzen einen Vertriebsdienstleister (VDL) ein. Der VDL ist ver- antwortliche Stelle (Verantwortlicher im datenschtzrechtlichen Sinne) und erbringt die Vertriebsdienstleistungen eigenverantwortlich. Die VDL der jeweiligen Teilnehmer sind Anlage 3 der Joint Controllership-Vereinbarung zu entnehmen.

21-10-01 Anlage 4 zum vHGS-Vertrag Teilnehmer Seite 7 von 10

[Seite 109]

1.3 Dienstleister

Folgende Teilnehmer treten primär in der KA-Rolle als Dienstleister mit dem Aufga- benbereich Kontrolle auf:

21-10-01 Anlage 4 zum vHGS-Vertrag Teilnehmer Seite 8 von 10

[Seite 110]

21-10-01 Anlage 4 zum vHGS-Vertrag Teilnehmer Seite 9 von 10

[Seite 111]

2 Externe Mandanten

Folgende Teilnehmer setzen ein eigenes Vertriebssystem ein und tauschen die Da- ten über die Bidirektionale Schnittstelle (vgl. Anlage 3) aus. Folgende Aufgabenberei- che nehmen sie dabei wahr:

21-10-01 Anlage 4 zum vHGS-Vertrag Teilnehmer Seite 10 von 10

[Seite 112]

Glossar vHGS

Glossar zum Vertrag über die

Nutzung, Teilnahme und Zusammenarbeit am verbundweiten

mandantenfähigen Hintergrundsystem (vHGS) des eTicket

RheinMain (vHGS-Vertrag)

Anlage 5 zum vHGS-Vertrag

[Seite 113]

Versionsverwaltung

21-10-01 Anlage 5 zum vHGS-Vertrag Glossar Seite 2 von 14

[Seite 114]

21-10-01 Anlage 5 zum vHGS-Vertrag Glossar Seite 3 von 14

[Seite 115]

21-10-01 Anlage 5 zum vHGS-Vertrag Glossar Seite 4 von 14

[Seite 116]

21-10-01 Anlage 5 zum vHGS-Vertrag Glossar Seite 5 von 14

[Seite 117]

21-10-01 Anlage 5 zum vHGS-Vertrag Glossar Seite 6 von 14

[Seite 118]

21-10-01 Anlage 5 zum vHGS-Vertrag Glossar Seite 7 von 14

[Seite 119]

21-10-01 Anlage 5 zum vHGS-Vertrag Glossar Seite 8 von 14

[Seite 120]

21-10-01 Anlage 5 zum vHGS-Vertrag Glossar Seite 9 von 14

[Seite 121]

21-10-01 Anlage 5 zum vHGS-Vertrag Glossar Seite 10 von 14

[Seite 122]

21-10-01 Anlage 5 zum vHGS-Vertrag Glossar Seite 11 von 14

[Seite 123]

21-10-01 Anlage 5 zum vHGS-Vertrag Glossar Seite 12 von 14

[Seite 124]

21-10-01 Anlage 5 zum vHGS-Vertrag Glossar Seite 13 von 14

[Seite 125]

Zertifikat Digitaler Datensatz, der bestimmte Eigenschaften von Personen oder Objekten (hier: relevanten Systemkomponenten des elektronischen Fahrgeldmanagements) bestätigt und dessen Authentizität und Integrität durch kryptografische Verfahren geprüft werden kann.

Anmerkungen:

In diesem Glossar nicht aufgeführte Abkürzungen und Fachbegriffe, aus dem Vertrag über die Teilnahme am (((eTicket Deutschland sind im dortigen Glossar [siehe: Kapitel 1 zum (((eTicket-Regelwerk] erläutert.

Erläuterungen zu Begriffen, die nicht vHGS-spezifisch sind, sind überwiegend aus der Dokumentation zur VDV-Kernapplikation (insbesondere KA-Glossar V1.107) übernommen.

21-10-01 Anlage 5 zum vHGS-Vertrag Glossar Seite 14 von 14

[Seite 126]

Auszug aus (((eTicket-TNV RMV

Auszug aus (((eTicket-Teilnahmevertrag

zwischen VDV-ETS KG

und RMV

Anlage 6 zum vHGS-Vertrag

[Seite 127]

Versionsverwaltung

21-10-01 Anlage 6 zum vHGS-Vertrag Auszug aus (((eTicket-TNV

[Seite 128]

(((eTicket Deutschland

(((eTicket-Teilnahmevertrag

Vertrag über die Teilnahme am (((eTicket-Deutschland

zwischen

VDV eTicket Service GmbH & Co. KG Im Mediapark 8a 50670 Köln

• nachstehend „VDV-ETS“ genannt -

und

• nachstehend „Teilnehmer“ genannt -

Vertragsnummer: _____

Seite 1 von 8

[Seite 129]

(((eTicket Deutschland

Stand: 01.08.2017

Seite 2 von 8

[Seite 130]

(((eTicket Deutschland

Präambel

1. Auf Initiative des Verbandes deutscher Verkehrsunternehmen (VDV) wurde gemeinsam mit Verkehrsunternehmen und der Industrie die VDV-Kernapplikation entwickelt und in die VDV-Kernapplikations Verwaltungsgesellschaft mbH eingebracht. Die Umsetzung des (((eTicket-Deutschland durch die VDV-eTicket Service GmbH & Co. KG und die Verkehrsunternehmen und Verbünde soll die Fahrgäste im ÖPV in die Lage versetzen, unter Nutzung nur noch eines einzigen elektronischen Nutzermediums (z.B. einer Chipkarte oder eines Mobiltelefons), bundesweit Beförderungsleistungen im ÖPV bargeldlos bezahlen und Fahrberechtigungen für die Nutzung des ÖPV erwerben zu können. Durch die Wahrung der Interoperabilität sind die von unterschiedlichen Verkehrsunternehmen und –verbünden herausgegebenen Nutzermedien in allen teilnehmenden (((eTicket- Deutschland-Regionen nutzbar. Das (((eTicket-Deutschland überwindet Grenzen zwischen Tarifen und Verkehrsunternehmen bzw. –verbünden. Damit wird dem Fahrgast der Zugang zum ÖPV erleichtert und die Nutzung öffentlicher Verkehrsmittel insgesamt attraktiver und einfacher gestaltet.

2. Technische und organisatorische Basis des (((eTicket-Deutschland ist die VDV- Kernapplikation, die den technischen Daten- und Schnittstellenstandard bildet und damit die Voraussetzung für das interoperable Zusammenwirken der jeweiligen (((eTicket-Systeme der Teilnehmer ist. Wesentlicher Bestandteil des (((eTicket- Deutschland ist das Rollenmodell der VDV-Kernapplikation.

3. Der Teilnehmer möchte am (((eTicket-Deutschland teilnehmen und wird im Rahmen des Rollenmodells die in § 1 dieses (((eTicket-Teilnahmevertrages (nachfolgend auch „TNV“) gekennzeichnete(n) Rolle(n) einnehmen.

4. Die in diesem (((eTicket-Teilnahmevertrag verwendeten Begriffe und Abkürzungen sind in der jeweils gültigen Fassung des Glossars in Kapitel 1 des (((eTicket- Regelwerks definiert.

§ 1 Vertragsgegenstand

1. Der Teilnehmer wird in den nachfolgend gekennzeichnete(n) Rolle(n) am (((eTicket- Deutschland teilnehmen (Mehrfachnennungen sind möglich):

 Produktverantwortlicher

 Dienstleister

 Kundenvertragspartner

2. Der Teilnehmer beabsichtigt grundsätzlich, die gemäß § 1 Abs. 3 gewählte(n) Ausbauvariante(n) vollständig umzusetzen. Die Ausbauvarianten sind in KA KUSCH- SPEC (vgl. Kapitel 3 Ziffer 10 des (((eTicket-Regelwerks) beschrieben. Vollständige Umsetzung im Sinne des Satzes 1 bedeutet den Einsatz der Ausbauvariante(n) im

Seite 3 von 8

[Seite 131]

(((eTicket Deutschland

Wirkbetrieb bei Umsetzung sämtlicher der jeweils pro Ausbauvariante seitens des Standards geforderten Anwendungsfälle und Elementarprozesse. Die Ausgabe des gesamten Tarifangebotes als elektronischer Fahrschein und das Angebot elektronischer Fahrscheine über sämtliche Vertriebskanäle sind keine notwendige Voraussetzung für eine vollständige Umsetzung.

3. Der Teilnehmer beabsichtigt, folgende Ausbauvariante(n) umzusetzen:

 (((eBezahlen (Ausbauvariante 1)

 (((eFahrschein mit (((eKontrolle (Ausbauvariante 2)

 Automatisierte Fahrpreisermittlung (Ausbauvariante 3)

4. Für die Teilnahme am (((eTicket-Deutschland gilt das als Anlage zu diesem (((eTicket-Teilnahmevertrag beigefügte (((eTicket-Regelwerk in seiner jeweils gültigen Fassung. Die VDV-ETS und der Teilnehmer verpflichten sich zur Einhaltung der in dem (((eTicket-Regelwerk enthaltenen Anforderungen. Soweit in dem (((eTicket- Regelwerk auf andere Dokumente verwiesen wird (insbesondere in Kapitel 3), sind auch diese Dokumente in ihrer jeweils gültigen Fassung Bestandteil des (((eTicket- Regelwerks und damit auch Bestandteil dieses (((eTicket-Teilnahmevertrages. Bei Widersprüchen zwischen den Regelungen dieses (((eTicket-Teilnahmevertrages und den Regelungen des (((eTicket-Regelwerks gehen die Regelungen dieses (((eTicket- Teilnahmevertrages vor.

5. Mit dem Abschluss dieses (((eTicket-Teilnahmevertrages erhält der Teilnehmer das Recht zum Bezug von Leistungen des Sicherheitsmanagementdienstleisters im Hinblick auf das Sicherheitsmanagement (vgl. (((eTicket-Regelwerk, Kapitel 2, § 4 Abs. 4). Die VDV-ETS verpflichtet sich, für den gesamten Vertragszeitraum die Erfüllung der Aufgabe des zentralen Sicherheitsmanagements durch einen von Ihr ausgewählten und beauftragten Sicherheitsmanagementdienstleister zu gewährleisten.

6. Das Angebot bzw. die Nutzung von alternativen Fahrscheinprodukten (Papierfahrscheinen, Handytickets, etc.) bleibt von der Teilnahme am (((eTicket- Deutschland unberührt.

7. Der Teilnehmer beantragt mit Unterzeichnung dieses Vertrags die Zuteilung einer Org-ID (Identifikationsnummer), sofern diese ihm nicht bereits erteilt wurde.

Ansprechpartner bei dem Verwender im Zusammenhang mit der Org-ID sind:

1.Ansprechpartner

Name, Vorname: ________________________________________

Telefon: ________________________________________

E-Mail-Adresse: ________________________________________

Seite 4 von 8

[Seite 132]

(((eTicket Deutschland

2.Ansprechpartner

Name, Vorname: ________________________________________

Telefon: ________________________________________

E-Mail-Adresse: ________________________________________

Änderungen bezüglich Namen des Unternehmens, Adresse und Ansprechpartner sind der VDV-ETS unverzüglich und unaufgefordert mitzuteilen. Dies gilt auch für den Fall, wenn das Unternehmen aufgelöst wird.

§ 2 Dauer des (((eTicket-Teilnahmevertrages / Kündigung

1. Dieser (((eTicket-Teilnahmevertrag wird zunächst für die Dauer von 24 Monaten geschlossen. Soweit der (((eTicket-Teilnahmevertrag nicht von dem Teilnehmer mit einer Frist von drei Monaten zum Ablauf der ersten Laufzeit nach Satz 1 gekündigt wird, verlängert er sich auf unbestimmte Zeit und kann anschließend von dem Teilnehmer mit einer Frist von drei Monaten zum Ende eines Kalenderjahres gekündigt werden. Ein ordentliches Kündigungsrecht der VDV-ETS gegenüber dem Teilnehmer ist ausgeschlossen. Die Kündigung bedarf der Schriftform unter Ausschluss der telekommunikativen Übermittlung.

2. Der (((eTicket-Teilnahmevertrag endet grundsätzlich, wenn der Teilnehmer nicht mehr Partei des Clearingvertrages ist.1 Die Parteien vereinbaren, sich gegenseitig rechtzeitig über Ihre Bestrebungen und evtl. vorgesehenen Maßnahmen zu informieren, um einvernehmliche Lösungsmöglichkeiten unter Berücksichtigung der beiderseitigen Interessen finden zu können.

3. Darüber hinaus bleibt das Recht der Parteien zur außerordentlichen Kündigung des (((eTicket-Teilnahmevertrages aus wichtigem Grund unberührt. Ein wichtiger Grund, der die VDV-ETS zu einer außerordentlichen Kündigung des (((eTicket- Teilnahmevertrages aus wichtigem Grund berechtigt, ist insbesondere jede wiederholte, nicht nur unerhebliche Verletzung der dem Teilnehmer nach dem (((eTicket-Teilnahmevertrag obliegenden Pflichten. Eine solche Pflichtverletzung liegt insbesondere vor, sobald sie geeignet ist, Schäden bei anderen Teilnehmern hervorzurufen oder die Systemintegrität zu beeinflussen. Ein wichtiger Grund für den Teilnehmer liegt insbesondere vor, wenn ein Verkehrsverbund, in dem der Teilnehmer beteiligt ist den Austritt aus dem (((eTicket-Deutschland beschlossen hat. Insofern ist es dem Teilnehmer auch möglich, eine Teilkündigung in Bezug auf einzelne Tarifgebiete auszusprechen.

4. Die in dem (((eTicket-Regelwerk enthaltenen Kündigungsrechte der Parteien bleiben unberührt.

1 Diese Regelung tritt erst in Kraft, sobald der Teilnehmer dem Clearingvertrag beigetreten ist.

Seite 5 von 8

[Seite 133]

(((eTicket Deutschland

5. Jeder außerordentlichen Kündigung in Folge von Pflichtverletzungen einer der Parteien hat eine schriftliche Abmahnung, in der das vertragswidrige Verhalten benannt ist, vorauszugehen. Die Kündigung bedarf der Schriftform unter Ausschluss der telekommunikativen Übermittlung.

6. Nach Kündigung des (((eTicket-Teilnahmevertrags ist dem Teilnehmer die reine Nutzung des Standards, bzw. von Teilen des Standards grundsätzlich weiterhin möglich. Dies erfolgt jedoch zu dann zu verhandelnden und entsprechend geänderten kaufmännischen Bedingungen, sofern der Teilnehmer nicht mehr die Public-Key- Infrastruktur (PKI) des Sicherheitsmanagementdienstleisters nutzt. Der nicht interoperable Weiterbetrieb darf zudem nicht mehr unter Nutzung der Marken und Geschmacksmuster des (((eTicket-Deutschland (i.S.d. (((eTicket-Regelwerks Kap. 4, § 1) stattfinden. Die VDV-ETS wird die technische Unterstützung weiterhin gewährleisten. Sofern der VDV-ETS im Rahmen der Umstellung, bzw. im Rahmen des nicht interoperablen Weiterbetriebs ohne Weiternutzung der PKI Kosten entstehen, sind diese vom ausscheidenden Teilnehmer zu tragen. Diese Kosten sind dem Teilnehmer jederzeit auf Anfrage verbindlich durch die VDV-ETS mitzuteilen.

§ 32 Beitritt zum Clearingvertrag

1. Der Teilnehmer erklärt seine Absicht, zum Zeitpunkt der Aufnahme des interoperablen Betriebs dem Clearingvertrag beitreten zu wollen. Die VDV-ETS wurde von den übrigen Teilnehmern bevollmächtigt, in deren Namen Beitrittserklärungen von künftigen Teilnehmern entgegenzunehmen und gegenüber diesen Teilnehmern die rechtsverbindliche Annahme der Beitrittserklärungen abzugeben.

2. Durch den Beitritt zum Clearingvertrag wird der Teilnehmer nicht gehindert, mit einzelnen oder allen übrigen Teilnehmern Vereinbarungen zu treffen, die von den Regelungen des Clearingvertrages abweichen und in deren Verhältnis dann vorrangig gelten. In diesem Fall entfaltet der Clearingvertrag keine Rechte und Pflichten für den Teilnehmer.

§ 4 Abweichungen von den Regelungen des (((eTicket-Teilnahmevertrags und des (((eTicket-Regelwerks während des Migrationszeitraums

Zur Erreichung der Interoperabilität verfolgen der Teilnehmer und die VDV-ETS das Ziel, dass in jeder Ausbauvariante eine (((eBezahlberechtigung an jeden Kunden ausgegeben wird, die jedem Kunden den Erwerb von Fahrscheinen bei Teilnehmern mit den Ausbauvarianten „(((eBezahlen“ und „(((eFahrschein mit (((eKontrolle“ und die Inanspruchnahme von Beförderungsleistungen bei Teilnehmern mit der Ausbauvariante „Automatisierte Fahrpreisermittlung“ ermöglicht.

2 § 3 gilt nur für Teilnehmer, die den (((eTicket-Teilnahmevertrag abschließen, nachdem der nach Maßgabe von Kapitel 7, Ziffer 3 des (((eTicket-Regelwerks verabschiedete Clearingvertrag vorliegt.

Seite 6 von 8

[Seite 134]

(((eTicket Deutschland

Die Parteien vereinbaren nachfolgende Abweichungen von den Regelungen des (((eTicket- Teilnahmevertrags und den (((eTicket-Teilnahmebedingungen (Kapitel 2 des (((eTicket- Regelwerks):

1. § 3 Abs. 3 h) und l) und § 3 Nr. 4 k) der (((eTicket-Teilnahmebedingungen findet erst Anwendung, wenn der Teilnehmer dem Clearingvertrag beigetreten ist.

§ 5 Nutzung des KOSE und der zentralen Vermittlungsstelle (ZVM)

1. Die Nutzung des Sperrlistenservices (KOSE) und der zentralen Vermittlungsstelle ist für den Teilnehmer kostenlos. Dies gilt für die Dauer der Vertragslaufzeit des mit dem derzeitigen Dienstleister geschlossenen Werk- und Betriebsvertrages vom 20.07.2010 (Anlage 8 zum (((eTicket-Regelwerk, siehe dort § 26). Sollten sich die kommerziellen Bedingungen in einem etwaigen Folgevertrag nach Kündigung für die VDV-ETS in nicht unerheblichem Maße nachteilig entwickeln, werden sich der Teilnehmer und die VDV-ETS um eine einvernehmliche Lösung bzgl. einer interessensgerechten Kostenbeteiligung bemühen, deren Realisierung auf Wunsch des Teilnehmers erst mit einem Jahr Verzögerung einsetzen kann. Eine Kündigung des Werk- und Betriebsvertrags durch die VDV-ETS darf erst nach Zustimmung der Gesellschafterversammlung erfolgen. Änderungen des Werk- und Betriebsvertrags bedürfen der Zustimmung der Teilnehmerversammlung.

2. Die VDV-ETS wird im Bedarfsfall sämtliche ihr gegen den KOSE-Dienstleister zustehenden Gewährleistungs- und Schadensersatzansprüche an den betroffenen Teilnehmer abtreten und den Teilnehmer bei der Verfolgung seiner Rechte unterstützen. Die VDV-ETS haftet nach der Maßgabe des Werk- und Betriebsvertrages anstelle des KOSE-Dienstleisters, soweit dieser aufgrund von Insolvenz vollständig oder teilweise mit der Erfüllung der Gewährleistungs- und Schadensersatzansprüche gegenüber dem Teilnehmer ausfällt.

3. Der Teilnehmer ist darüber unterrichtet, dass die Herstellung der Schnittstelle zum KOSE, bzw. zur zentralen Vermittlungsstelle im eigenen Hintergrundsystem auf eigene Kosten zu erfolgen hat. Hierzu wird die VDV-ETS beim KOSE-Dienstleister darauf hinwirken, dass dieser eine vereinfachte, standardisierte Lösung zur Anschlusserleichterung zur Verfügung stellen wird. Des Weiteren wird die VDV-ETS sicherstellen, dass der von ihr beauftragte Anbieter des KOSE eine Service-Hotline für alle laufenden und projektbezogenen Abstimmungen und Tests mit dem Anbieter des Hintergrundsystems des jeweiligen Teilnehmers anbietet.

§ 6 Schlussbestimmungen

1. Erfüllungsort ist Köln. Ausschließlicher Gerichtsstand für alle Streitigkeiten, die aus diesem (((eTicket-Teilnahmevertrag resultieren, ist Köln.

2. Dieser (((eTicket-Teilnahmevertrag unterliegt deutschem Recht.

Seite 7 von 8

[Seite 135]

(((eTicket Deutschland

3. Soweit in dem (((eTicket-Regelwerk nichts anderes geregelt ist, bedürfen Änderungen oder Ergänzungen dieses (((eTicket-Teilnahmevertrages sowie dessen Aufhebung zu ihrer Wirksamkeit der Schriftform (keine elektronische Form, telekommunikative Übermittlung nur per Telefax). Gleiches gilt für die Aufhebung des Schriftformerfordernisses.

4. Sollten in diesem (((eTicket-Teilnahmevertrag einzelne Bestimmungen rechtsunwirksam sein oder werden, so sind die Vertragsparteien darüber einig, dass dadurch die Gültigkeit der übrigen Bestimmungen nicht beeinträchtigt werden soll. Die unwirksame Bestimmung ist durch eine rechtswirksame Regelung zu ersetzen, die dem wirtschaftlichen Zweck der unwirksamen Bestimmung am nächsten kommt. Dasselbe gilt, wenn bei Durchführung dieses (((eTicket-Teilnahmevertrages eine ergänzungsbedürftige Regelungslücke offenbar wird.

§ 7 Vertragsbestandteile

1. Folgende Anlagen werden Bestandteile dieses Teilnahmevertrages:

Anlage 1: (((eTicket-Regelwerk Anlage 2: Migrationsszenarien in den Ausbauvarianten des (((eTicket Deutschland Anlage 3: Muster-Kundenverträge nebst Allgemeinen Geschäftsbedingungen Anlage 4: Muster Datenschutz-Hinweise Anlage 5: Geschäftsordnung für die Teilnehmerversammlung Anlage 6: Geschäftsordnung für die AG Standardisierung

2. Bei Widersprüchen zwischen den Bestimmungen dieses Teilnahmevertrages und den Bestandteilen (Anlagen) gehen die Bedingungen dieses Teilnahmevertrages vor; die Bestandteile gelten bei Widersprüchen unabhängig von der Anlagennummerierung in der angegebenen Reihenfolge.

______________, den Köln, den

Teilnehmer VDV eTicket Service GmbH & Co. KG

Jozef A.L. Janssen, Geschäftsführer

Seite 8 von 8