<?xml version="1.0" encoding="UTF-8"?>
<!-- Mit XMLSpy v2011 rel. 2 (x64) (http://www.altova.com) von STUZZA (STUZZA) bearbeitet -->
<!-- edited with XMLSpy v2015 sp2 (x64) (http://www.altova.com) by Helmut Biely (self employed) -->
<xs:schema xmlns="http://www.Stuzza.at/MBS/V7.0.04/Reply" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.Stuzza.at/MBS/V7.0.04/Reply" elementFormDefault="qualified" attributeFormDefault="unqualified">
	<!--  *******************************************************************************-->
	<!--  ***  Änderung gegenüber Version  6001                                      ***-->
	<!--  ***  o Validation Subset in FileIdType eingefügt                             ***-->
	<!--  ***  o Alrt bei EBZ Abholung erweitert, Kommentare ergänzt        ***-->
	<!--  ***  o Image entfernt, Renumerierung verschiedener Type-Def    ***-->
	<!--  ***  o KOP/FileId Kommentar überarbeitet (EDI, Container)            ***-->
	<!--  ***  o TpType_3 CAMT086 eingefügt                                             ***-->
	<!--  ***  o APCNmSpceType enumeration befüllt                                  ***-->
	<!--  ********************************************************************************-->
	<!--  ***  Änderung gegenüber Version  7.0.01                                     ***-->
	<!--  ***  o MsgId MaxLen = 35                                                              ***-->
	<!--  ***  o BIC aus  AcctType und AcctType1  entfernt                        ***-->
	<!--  ********************************************************************************-->
	<!--  ***  Änderung gegenüber Version  7.0.02                                    ***-->
	<!--  ***  o APCNmSpceType  entfernt                                                  ***-->
	<!--  ***  o VldtnSubSet: gültige Namespaces in Kommentar eingef.    ***-->
	<!--  ********************************************************************************-->
	<!--  ***  Änderung gegenüber Version  7.0.03                                     ***-->
	<!--  ***  o keine - ausschließlich Anpassung der Version auf 7.0.04  ***-->
	<!--  ********************************************************************************-->
	<!--  ***  Änderung gegenüber Version  7.0.04                                     ***-->
	<!--  ***  o Korrektur zum Kommentar des Alrt-Attribut                         ***-->
	<!--  ********************************************************************************-->
	<!--  ***  Änderung gegenüber VD=10.06.2016                                     ***-->
	<!--  ***  o Kommentar zu RstrtDtTm bei Typ KTO korrigiert                   ***-->
	<!--  ********************************************************************************-->
	<xs:attribute name="versiondate" fixed="25.07.2016">
		<xs:annotation>
			<xs:documentation xml:lang="de">Versionsdatum dieses Schemas</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<!--Root element-->
	<xs:element name="Document" type="Document">
		<xs:annotation>
			<xs:documentation>Root Element</xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:complexType name="AcctType">
		<xs:sequence>
			<xs:element name="IBAN" type="IBANIdentifier"/>
		</xs:sequence>
		<xs:attribute name="Ccy" type="CurrencyCode" default="EUR">
			<xs:annotation>
				<xs:documentation>Kontowährung</xs:documentation>
			</xs:annotation>
		</xs:attribute>
	</xs:complexType>
	<xs:complexType name="AcctType1">
		<xs:choice>
			<xs:element name="IBAN" type="IBANIdentifier">
				<xs:annotation>
					<xs:documentation>IZV: Ausschliesslich AT-IBANs sind gültig!</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="NonDmstAcct" type="SWIFTAcctTp">
				<xs:annotation>
					<xs:documentation>AZV: es sind alle Definitionen zulässig, die bei der Anlage eines SWIFT Kontos in MBS auftreten dürfen. Dies ist eine verkürzte Version gegenüber den Kontoverbindungen die ein AustrianN-pain001 erlaubt .</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:choice>
		<xs:attribute name="Ccy" type="CurrencyCode">
			<xs:annotation>
				<xs:documentation>Währung des Kontos</xs:documentation>
			</xs:annotation>
		</xs:attribute>
	</xs:complexType>
	<xs:simpleType name="AlrtType">
		<xs:restriction base="xs:string">
			<xs:enumeration value="EBZ_TRANS"/>
			<xs:enumeration value="EBZ_BIGDATA"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="BtchRefType">
		<xs:restriction base="xs:positiveInteger">
			<xs:totalDigits value="5"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="CountryCode">
		<xs:restriction base="xs:string">
			<xs:pattern value="[A-Z]{2,2}"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="CurrencyCode">
		<xs:restriction base="xs:string">
			<xs:length value="3"/>
			<xs:pattern value="[A-Z]*"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:complexType name="Document">
		<xs:sequence>
			<xs:element name="MBS_Reply_Message" type="MBS_Reply_Message_Type"/>
		</xs:sequence>
	</xs:complexType>
	<xs:simpleType name="EbzIdType">
		<xs:restriction base="xs:string">
			<xs:length value="16"/>
			<xs:pattern value="[A-Z0-9\-]*"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:complexType name="FileIdType">
		<xs:sequence>
			<xs:element name="SsnId" type="SsnIdType">
				<xs:annotation>
					<xs:documentation>Session Id (8 hexadezimale Stellen in 4 Byte) 
der aktuellen MBS Session</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="FileNb">
				<xs:annotation>
					<xs:documentation>Filenummer innerhalb der Session</xs:documentation>
				</xs:annotation>
				<xs:simpleType>
					<xs:restriction base="xs:positiveInteger">
						<xs:totalDigits value="5"/>
					</xs:restriction>
				</xs:simpleType>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="FileIdTypeK">
		<xs:sequence>
			<xs:element name="SsnId" type="SsnIdType">
				<xs:annotation>
					<xs:documentation>Session Id (8 hexadezimale Stellen in 4 Byte) 
der aktuellen MBS Session</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="FileNb">
				<xs:annotation>
					<xs:documentation>Filenummer innerhalb der Session</xs:documentation>
				</xs:annotation>
				<xs:simpleType>
					<xs:restriction base="xs:positiveInteger">
						<xs:totalDigits value="5"/>
					</xs:restriction>
				</xs:simpleType>
			</xs:element>
			<xs:element name="VldtnSubSet" minOccurs="0">
				<xs:annotation>
					<xs:documentation>Im Fall einer Kontonachricht des SubTp=Camt052, 053 oder 054 ist hier die Validation Sub Set anzugeben, mit dem der Camt zu validieren ist. Sonst nicht zu verwenden. Das Validation Sub Set ist im Format
					"ISO:camt.05n.001.02:APC:STUZZA:payments:00m" mit n=2, 3 oder 4 und m=3 oder 4 zu kodieren.
					
Wird kein Validation Subset für Camts kodiert, muss der betreffende Camt an Stelle des ISO den APC name space beinhalten.	</xs:documentation>
				</xs:annotation>
				<xs:simpleType>
					<xs:restriction base="xs:string">
						<xs:minLength value="43"/>
						<xs:maxLength value="45"/>
					</xs:restriction>
				</xs:simpleType>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="GrpHdrType1">
		<xs:sequence>
			<xs:element name="MsgId" type="MsgId">
				<xs:annotation>
					<xs:documentation>Eindeutige Identifikation der Nachricht. Aufbau: Stellen 1 bis 16 Timestamp im Format  JJJJMMTTHHMMSShh, 4   Zufallszeichen zwingend bis zu 15 weitere Zufallszeichen optional.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="CreDtTm" type="ISODateTime">
				<xs:annotation>
					<xs:documentation>Zeitstempel des Erstellungszeitpunkts der Nachricht</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:simpleType name="IBANIdentifier">
		<xs:restriction base="xs:string">
			<xs:pattern value="[a-zA-Z]{2,2}[0-9]{2,2}[a-zA-Z0-9]{1,30}"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="ISODateTime">
		<xs:restriction base="xs:dateTime"/>
	</xs:simpleType>
	<xs:simpleType name="Max34Text">
		<xs:restriction base="xs:string">
			<xs:minLength value="1"/>
			<xs:maxLength value="34"/>
			<xs:whiteSpace value="preserve"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Max35Text">
		<xs:restriction base="xs:string">
			<xs:minLength value="1"/>
			<xs:maxLength value="35"/>
			<xs:whiteSpace value="preserve"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Max140Text">
		<xs:restriction base="xs:string">
			<xs:minLength value="1"/>
			<xs:maxLength value="140"/>
			<xs:whiteSpace value="preserve"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:complexType name="MBS_Reply_Message_Type">
		<xs:sequence>
			<xs:element name="GrpHdr" type="GrpHdrType1"/>
			<xs:element ref="MBS_Reply_Message_EBZ" minOccurs="0"/>
			<xs:element ref="MBS_Reply_Message_KOP" minOccurs="0"/>
			<xs:element ref="MBS_Reply_Message_KTO" minOccurs="0"/>
			<xs:element ref="MBS_Reply_Message_PDF" minOccurs="0"/>
		</xs:sequence>
	</xs:complexType>
	<xs:element name="MBS_Reply_Message_EBZ">
		<xs:annotation>
			<xs:documentation>MBS Antwortmessage EBZ: zur Übermittlung von eBZ</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="RpIyInf" type="RplyInfType" maxOccurs="unbounded">
					<xs:annotation>
						<xs:documentation>EBZ können auf Grund einer Anforderung oder als Antwort auf übermittelte Aufträge an den Client geliefert werden. Innerhalb einer Nachricht können EBZ aus beiden Gründen bunt gemischt auftreten.</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
	<xs:element name="MBS_Reply_Message_KOP">
		<xs:annotation>
			<xs:documentation>MBS Antwortmessage KOP: zur Übermittlung von Auftragskopien</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="RpIyInf" type="RplyInfType_1" maxOccurs="unbounded"/>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
	<xs:element name="MBS_Reply_Message_KTO">
		<xs:annotation>
			<xs:documentation>MBS Antwortmessage KTO: zur Übermittlung von Auszügen, Belegen,Retourdatenträger und ISO-Statusmessages</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="RpIyInf" type="RplyInfType_2" maxOccurs="unbounded"/>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
	<xs:element name="MBS_Reply_Message_PDF">
		<xs:annotation>
			<xs:documentation>MBS Antwortmessage PDF: zur Übermittlung von PDF- Auszügen bzw. deren eKA-Referenznummer</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="RpIyInf" type="RplyInfType_3" maxOccurs="unbounded">
					<xs:annotation>
						<xs:documentation>Es wird mit der Antwortmessage lediglich eine Referenznummer an den MBS Client übermittelt, mit der die eigentlichen elektronischen Kontoauszüge asynchron vom Bankrechner  abgeholt werden können.  Im Fall von signierten eKA ist eine Überprüfung der Signatur durch MBS Client nicht vorgesehen</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
	<xs:simpleType name="MsgId">
		<xs:restriction base="xs:string">
			<xs:minLength value="20"/>
			<xs:maxLength value="35"/>
			<xs:whiteSpace value="collapse"/>
			<xs:pattern value="2[0-9]{15}[A-Z0-9]{4,}"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="RefNumType">
		<xs:restriction base="xs:string">
			<xs:minLength value="1"/>
			<xs:maxLength value="35"/>
			<xs:whiteSpace value="collapse"/>
			<xs:pattern value=".*\S+.*"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:complexType name="RefsType">
		<xs:sequence>
			<xs:element name="SsnId">
				<xs:annotation>
					<xs:documentation>Id der MBS-IP Session  (8 hexadezimale Stellen in 4 Byte)  mit der der originäre EBZ/TBZ oder die Anforderungsnachricht übermittelt wurden</xs:documentation>
				</xs:annotation>
				<xs:simpleType>
					<xs:restriction base="SsnIdType"/>
				</xs:simpleType>
			</xs:element>
			<xs:element name="MsgRef" type="MsgId">
				<xs:annotation>
					<xs:documentation>MsgId der Anforderungsmessage bzw. des originären EBZ/TBZ  wenn Alrt gesetzt wurde.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="BtchRef" type="BtchRefType" minOccurs="0">
				<xs:annotation>
					<xs:documentation>Angabe BtchCtr der Anforderungsnachricht als optionale Ergänzung zur MsgRef, wenn diese für eine eindeutigev Refernzeireung nicht ausreicht.

Nicht in Verbindung mit EbzId zu kodieren</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="EbzId" type="EbzIdType" minOccurs="0">
				<xs:annotation>
					<xs:documentation>EBZ Identifikatiosnnummer, ist nur dann zu kodieren, wenn auch die Anforderung mittels EbzId erfolgte.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="RestrtDtTm" type="ISODateTime" minOccurs="0">
				<xs:annotation>
					<xs:documentation>Erfolgte die  Anforderung mit RestrtDtTm dann muss der BR hier einen  Wiederaufsetzzeitpunkt  für die nächste Anforderung zur Sicherung einer lückenlose Informationskette mitgeben. Das Feld  ist  vom Client zwingend als Wiederaufsetzdatum zu verwenden.</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
		<xs:attribute name="Alrt" type="AlrtType">
			<xs:annotation>
				<xs:documentation>Nur für die Kennzeichnung eines nicht auf Grund einer Anforderungsnachricht übermittelten EBZ; es sind zwei Fälle zu unterscheiden:

   o  Erfolgt die Lieferung des EBZ auf Grund eines vom Kunden gesendeten
EBZ, so ist EBZ_TRANS  zu kodieren.

   o  Wurden auf Basis eines TBZ ein oder mehrere EBZ am BR erstellt, sind diese durch EBZ_BIGDATA zu kennzeichnen.

Sonst nicht zu kodieren.

War der übermittelte EBZ/TBZ  fehlerhaft, sodass eine Ergänzung bzw. Erstellung  des EBZ durch den BR nicht möglich war, ist an Stelle des EBZ eine negative Statusantwort 670 zu senden.</xs:documentation>
			</xs:annotation>
		</xs:attribute>
	</xs:complexType>
	<xs:complexType name="RefsType_1">
		<xs:sequence>
			<xs:element name="SsnId" type="SsnIdType">
				<xs:annotation>
					<xs:documentation>Id der MBS-IP Session  (8 hexadezimale Stellen in 4 Byte)  mit der die Anforderungsnachricht übermittelt wurde</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="MsgRef" type="MsgId">
				<xs:annotation>
					<xs:documentation>MsgId der Anforderungsmessage</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="BtchRef">
				<xs:annotation>
					<xs:documentation>Inhalt des BtchCtr der Anforderungsmessage</xs:documentation>
				</xs:annotation>
				<xs:simpleType>
					<xs:restriction base="BtchRefType">
						<xs:minInclusive value="1"/>
						<xs:maxInclusive value="99999"/>
					</xs:restriction>
				</xs:simpleType>
			</xs:element>
			<xs:element name="RestrtDtTm" type="ISODateTime" minOccurs="0">
				<xs:annotation>
					<xs:documentation>Erfolgte die  Anforderung mit RestrtDtTm dann muss der BR hier einen  Wiederaufsetzzeitpunkt  für die nächste Anforderung zur Sicherung einer lückenlose Informationskette mitgeben.

Im Fall von ISO-Statusnachrichten kann die Angabe (während einer Übergangsphase) entfallen, soferen der BR geeignet Massnahmen trifft, die eine Doppelübertragung identer Informationen verhindern.

Wird das Feld kodiert ist es vom Client zwingend als Wiederaufsetzdatum zu verwenden.</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="RefsType_2">
		<xs:sequence>
			<xs:element name="SsnId" type="SsnIdType">
				<xs:annotation>
					<xs:documentation>Id der MBS-Session  (8 hexadezimale Stellen in 4 Byte)  mit der die Anforderungsnachricht übermittelt wurde</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="MsgRef" type="MsgId">
				<xs:annotation>
					<xs:documentation>MsgId der Anforderungsmessage</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="BtchRef" type="BtchRefType">
				<xs:annotation>
					<xs:documentation>Inhalt des BtchCtr der Anforderungsmessage</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="RplyInfType">
		<xs:sequence>
			<xs:element name="Tp" type="TpType_1">
				<xs:annotation>
					<xs:documentation>EBZ definiert die Nachricht als EBZ-Übermittlung.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="Refs" type="RefsType"/>
			<xs:element name="FileId" type="FileIdType" maxOccurs="unbounded">
				<xs:annotation>
					<xs:documentation>Referenz auf ein oder mehrere FileIds, abhängig von der Anforderungsart bzw. davon, ob ein EBZ auf Grund übermittelter Aufträge retourniert wird.
 
Wurden in Refs Alrt=EBZ_TRANS oder EbzId kodiert wird hier genau ein EBZ mittels einer FileId referenziert. Wurde in Refs ALRT=EBZ_BIGDATA kodiert, können abhängig von der Kodierung des SpltInd im zu Grunde liegenden TBZ ein oder mehrere EBZ retourniert werden. Bei einer Anforderung über die Rolle eines Verfügers (TpVerf) können  beliebig viele EBZ übermittelt und dementsprechend mehrere FileIds referenziert werden. 

Im Fall einer Anforderung mittels TpVerf ist bei der Zusammenstellung der Antwortmessage die Art und der Aufbau der Anforderung genau zu beachten, insbesondere, ob die Anforderungen zu den einzelnen Konten in getrennten EBZ Request Messages oder in einer Request Message erfolgten; dabei gilt:
o	Wurden mehrere Request Messages übermittelt so werden EBZ ggf. auch mehrfach übertragen, da seitens des BR in diesem Fall keine Querprüfung über die einzelnen Request Messages erfolgt.
o	Erfolgte die Anforderung in einer Request Message mit mehreren ReqInf, so hat der BR zu überprüfen, ob ggf. die Anforderungen von späteren ReqInf  nicht bereits durch die Beantwortung von früheren ReqInf erfüllt wurden. Wurde etwa eine Anforderung auf z.B. drei Konten übermittelt und in der Antwort auf die ReqInf auch die Anforderungen der zweiten und dritten ReqInf bereits erfüllt, so erfolgt auf die beiden letzteren die Status Message 751 "Keine zusätzlichen eBZ vorhanden", wobei diese Statusmessage nicht dem Kunden angezeigt wird, sondern vom PC-Paket intern verarbeitet wird (alle drei Anforderungen wurden mit der Antwort auf die erste Anforderung befriedigt). 
o	Erfolgte die Anforderung mit SubTp="alle offen" und kann kein  EBZ geliefert werden, so ist mit Status Message 752 "Keine offenen Zeichnungen" zu antworten.
</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="RplyInfType_1">
		<xs:sequence>
			<xs:element name="Tp" type="TpType_2">
				<xs:annotation>
					<xs:documentation>KOP definiert die Nachricht als Antwort auf die Anforderung von Auftragskopien</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="Refs" type="RefsType_2"/>
			<xs:element name="FileId" type="FileIdType" maxOccurs="unbounded">
				<xs:annotation>
					<xs:documentation>Unabhängig davon, ob die Anforderung der KOP Request Message Datenträger im XML Format (SCT oder SDD) oder IM SWIFT-Format (MT101) enthält, so werden diese sortenrein in eigene Antwortfiles eingestellt, die mittels FileId referenziert werden, wobei je Datenträger ein eigener Antwortfile erstellt wird.

Bei Kopien von XML Aufträgen kann es sich auch um die Kopie eines XML Containers handeln (THM-Aufträge), der vollständig zu übermitteln ist und in einem Antwortfile eingestellt wird.
</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="RplyInfType_2">
		<xs:sequence>
			<xs:element name="SubTp">
				<xs:annotation>
					<xs:documentation>Abhängig von den übertragenen Daten ist Tp entsprechend der Aufzählung zu kodieren.</xs:documentation>
				</xs:annotation>
				<xs:complexType>
					<xs:simpleContent>
						<xs:extension base="TpType_3"/>
					</xs:simpleContent>
				</xs:complexType>
			</xs:element>
			<xs:element name="Acct" type="AcctType1">
				<xs:annotation>
					<xs:documentation>Das den übertragenen Auszügen, Belegen, Retourdatenträger etc. zugehörige Konto.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:sequence>
				<xs:element name="Refs" type="RefsType_1"/>
				<xs:element name="InfTxt" type="Max140Text" minOccurs="0">
					<xs:annotation>
						<xs:documentation>Im Fall von Teillieferungen ist InfTxt ein entsprechender Hinweis verpflichtend einzustellen.  Können z.B. nicht alle ab StrtStmtNb angeforderten Auszüge geliefert werden, wäre ein entsprechneder Hinweis: "Auszüge erst ab Auszugsnummer nnn lieferbar" anzubringen.</xs:documentation>
					</xs:annotation>
				</xs:element>
				<xs:element name="FileId" type="FileIdTypeK" maxOccurs="unbounded">
					<xs:annotation>
						<xs:documentation>In FileId ist die Referenznummer jenes File anzugeben, in dem die angeforderten Kontoinformationen  übertragen werden. Die Informationen werden im nativen Format, also SWIFT bzw. XML, in die Dateien eingestellt. 

Der derart referenzierte File enthält die angeforderten Informationen für die folgenden Kodierungen von Tp:
o  MT940	SWIFT MT940 Kontoauszüge
o  MT941	SWIFT MT941 Kontosalden
o  MT942	SWIFT MT942 Kontovormerkungen
o  BELEG	Zu Kontoauszügen zugehörige Belege
o  DAAB  	Informationen zu Daueraufträgen
o  CREMUL	EDI Retourdatenträger CREMUL
o  DEBMUL	EDI Retourdtaenträger DEBMUL
o  CAMTn	CAMT Anforderungen der Typen 052, 053 und 054
o  ISOSTS	ISO Statusnachrichten
o  CAMT086	Spesenaufstellung
o  DEPOT	Depotauszug

Jedes Data Element enthält maximal einen vollständigen Kontoauszug, Belegstapel, Retourdatenträger etc. 
Ein Kontoauszug ist durch eine gleichbleibende Auszugsnummer in Feldart 28C definiert und kann sich über bis zu 999 Seiten (Seitennummer in Feldart 28C) erstrecken. Analoges gilt für Kontovormerkungen und Belegdaten.
Werden mehrere Auszüge, also Auszüge mit unterschiedlichen Auszugsnummern, zu einem Konto übertragen, so ist je Auszug ein eigenes Data Element auf zu machen. Sinngemäßes gilt für die Belegdaten zu einem Auszug, und Retourdatenträger. 

Für Kontoauszüge und –Vormerkungen ist die Größe je Seite gemäß SWIFT mit 10K limitiert.
.</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="RplyInfType_3">
		<xs:sequence>
			<xs:element name="Tp" type="TpType_4">
				<xs:annotation>
					<xs:documentation>PDF definiert die Nachricht als Antwort auf eine eKA Anforderung</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="Acct" type="AcctType">
				<xs:annotation>
					<xs:documentation>Zu den eKA Informationen zugehöriges Konto</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:sequence>
				<xs:element name="Refs" type="RefsType_2">
					<xs:annotation>
						<xs:documentation>Referenzierung der Anforderung</xs:documentation>
					</xs:annotation>
				</xs:element>
				<xs:element name="FileId" type="FileIdType">
					<xs:annotation>
						<xs:documentation>In FileId ist die Referenznummer jenes File anzugeben, in dem die angeforderten PDF Auszüge als ZIP gepackt übertragen werden.</xs:documentation>
					</xs:annotation>
				</xs:element>
				<xs:element name="RestrtDtTm" type="ISODateTime" minOccurs="0">
					<xs:annotation>
						<xs:documentation>RestrtDtTm ist nur dann zu kodieren, wenn die Anforderung mittels RestrtDtTm oder mittels StartDt erfolgte und keine EndDt in der PDF Request Message kodiert war. 
Mit RestrtDtTm wird dem MBS Client das Restart Datum und Uhrzeit für die nächste Anforderung mitgeteilt um eine lückenlose Lieferung von eKA zum in Acct angegebenen Konto zu gewährleisten.</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:sequence>
	</xs:complexType>
	<xs:simpleType name="SsnIdType">
		<xs:annotation>
			<xs:documentation>hexBinary in der Länge 4 für die Aufnahme von 8 hexadezimalen Stellen</xs:documentation>
		</xs:annotation>
		<xs:restriction base="xs:hexBinary">
			<xs:length value="4"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:complexType name="SWIFTAcctTp">
		<xs:sequence>
			<xs:element name="CtrCd" type="CountryCode"/>
			<xs:element name="OthrInstnId" type="Max35Text"/>
			<xs:element name="OthrAcctId" type="Max34Text">
				<xs:annotation>
					<xs:documentation>Kontonummer</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:simpleType name="TpType_1">
		<xs:restriction base="xs:string">
			<xs:length value="3"/>
			<xs:enumeration value="EBZ"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="TpType_2">
		<xs:restriction base="xs:string">
			<xs:length value="3"/>
			<xs:enumeration value="KOP"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="TpType_3">
		<xs:restriction base="xs:string">
			<xs:maxLength value="7"/>
			<xs:minLength value="4"/>
			<xs:enumeration value="MT940"/>
			<xs:enumeration value="MT941"/>
			<xs:enumeration value="MT942"/>
			<xs:enumeration value="BELEG"/>
			<xs:enumeration value="DAAB"/>
			<xs:enumeration value="CREMUL"/>
			<xs:enumeration value="DEBMUL"/>
			<xs:enumeration value="CAMT052"/>
			<xs:enumeration value="CAMT053"/>
			<xs:enumeration value="CAMT054"/>
			<xs:enumeration value="CAMT086"/>
			<xs:enumeration value="ISOSTS"/>
			<xs:enumeration value="DEPOT"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="TpType_4">
		<xs:restriction base="xs:string">
			<xs:length value="3"/>
			<xs:enumeration value="PDF"/>
		</xs:restriction>
	</xs:simpleType>
</xs:schema>
