<?xml version="1.0" encoding="UTF-8"?>
<!-- Mit XMLSpy v2011 rel. 2 (http://www.altova.com) von STUZZA (STUZZA) bearbeitet -->
<!-- edited with XMLSpy v2013 sp1 (http://www.altova.com) by Helmut Biely (private) -->
<xs:schema xmlns="http://www.Stuzza.at/MBS/V6.0.01/Reply" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.Stuzza.at/MBS/V6.0.01/Reply" elementFormDefault="qualified" attributeFormDefault="unqualified">
	<!--  *******************************************************************************-->
	<!--  ***  Änderung gegenüber Vorversion                                          ***-->
	<!--  ***  o Erweiterung der Acct Definition  im Fall KTO                      ***-->
	<!--  ***  o Erweiterung der Tp Definition (DAAB) im Fall KTO             ***-->
	<!--  ***  o Korrektur des Kommentars zu KTO Feld FileId                   ***-->
	<!--  *******************************************************************************-->
	<!--  ***  Änderung gegenüber Version  15.12.2011                            ***-->
	<!--  ***  o Korrektur div. Tippfehler                                                      ***-->
	<!--  *******************************************************************************-->
	<!--  ***  Änderung gegenüber Version  25.01.2012                            ***-->
	<!--  ***  o GrpHdr herausgezogen aus Teilnachrichten                      ***-->
	<!--  ***  o Teilnachrichten max. einmal; Wiederh. über ReplyInf          ***-->
	<!--  ***  o TpTypes Länge auf 3 vereinheitlicht.                                   ***-->
	<!--  ***  o  ReqRef auf BtchRef geändert                                            ***-->
	<!--  ***  o  BtchRef bei EBZ eingeführt                                                ***-->
	<!--  ***  o Type TP beo KTO auf SubTp geändert                                ***-->
	<!--  ********************************************************************************-->
	<!--  ***  Änderung gegenüber Version  15.03.2012                             ***-->
	<!--  ***  o optionales RestrtDtTm Stamp in RefsType1                          ***-->
	<!--  ********************************************************************************-->
	<!--  ***  Änderung gegenüber Version  30.03.2012                             ***-->
	<!--  ***  o RefsType3 ohne RestrtDtTm Stamp                                      ***-->
	<!--  ********************************************************************************-->
	<!--  ***  Änderung gegenüber Version  03.07.2012                              ***-->
	<!--  ***  o Korrektur der Länge von SsnIdType auf 4 Byte                    ***-->
	<!--  *********************************************************************************-->
	<!--  ***  Änderung gegenüber Version  01.08.2012                              ***-->
	<!--  ***  o BtchRefType auf positiveInteger geändert                            ***-->
	<!--  ***  o Klarstellung MBS-Session in versch. Kommentaren              ***-->
	<!--  ***  o Klarstellung  Kommentar zur Länge des SsnIdType              ***-->
	<!--  ***  o Klarstellung  Kommentar zur Verwendung von RestrtDtTm  ***-->
	<!--  ***  o Ergänzung TpTyp3 um den Wert "DEPOT"                             ***-->
	<!--  ***  o FileNb in FileIdType auf positiveInteger geändert                   ***-->
	<!--  *********************************************************************************-->
	<!--  ***  Änderung gegenüber Version  14.09.2012                              ***-->
	<!--  ***  o Einfügung RestrtDtTm in RefsType (EBZ)                              ***-->
	<!--  ***  o Korrektur Kommentar KOP: DIRDEB statt DEBMUL                ***-->
	<!--  ***  o Ergänzug Kommentar KOP: MT101 und EDI Regeln               ***-->
	<!--  ***  o TpType2: Enum  auf KOP geändert  (Vereinheitlichung)        ***-->
	<!--  ***  o Korrektur Schreibweisen in FileId und RplyInfTypes             ***-->
	<!--  *********************************************************************************-->
	<!--  ***  Änderung gegenüber Version  14.09.2012                              ***-->
	<!--  ***  o Reply Type PDF: RstrtDtTm an Stelle RstrtDt                         ***-->
	<!--  *********************************************************************************-->
	<!--  ***  Änderung gegenüber Version  12.12.2012                              ***-->
	<!--  ***  o Namensvereinheitlichung: RestrtDtTm in Reply Type IMG     ***-->
	<!--  *********************************************************************************-->
	<!--  ***  Änderung gegenüber Version  25.01.2013                              ***-->
	<!--  ***  o Korrektur des Hinweises zur 10K Grenze bei MT940/2        ***-->
	<!--  *********************************************************************************-->
	<!--  ***  Änderung gegenüber Version  01.02.2013                              ***-->
	<!--  ***  o Korrektur im Kommentar zu  Alrt in Refs der EBZ-Reply       ***-->
	<!--  ***  o Korrektur im Kommentar zu DocTp in Prcg der IMG-Reply    ***-->
	<!--  *********************************************************************************-->
	<!--  ***  Änderung gegenüber Version  05.04.2013                              ***-->
	<!--  ***  o Korrektur im Kommentar zu RplyInfType_2 (KOP) im Fall EDI ***-->
	<!--  *********************************************************************************-->
	<!--  ***  Änderung gegenüber Version  01.08.2013                              ***-->
	<!--  ***  o Anpassung im Kommentar zu RplyInfType_2 (KOP)bei EDI   ***-->
	<!--  *********************************************************************************-->
	<xs:attribute name="versiondate" fixed="120813">
		<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="BIC" type="BICIdentifier"/>
			<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:sequence>
				<xs:element name="BIC" type="BICIdentifier"/>
				<xs:element name="IBAN" type="IBANIdentifier">
					<xs:annotation>
						<xs:documentation>IZV: Ausschliesslich AT-IBANs sind gültig!</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:sequence>
			<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:length value="9"/>
			<xs:enumeration value="EBZ_TRANS"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="BICIdentifier">
		<xs:restriction base="xs:string">
			<xs:pattern value="[A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}"/>
		</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:simpleType name="DocIdType">
		<xs:restriction base="xs:string">
			<xs:length value="3"/>
			<xs:enumeration value="006"/>
			<xs:enumeration value="009"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="DocTpType">
		<xs:restriction base="xs:string">
			<xs:length value="2"/>
		</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:simpleType name="FdeOutType">
		<xs:restriction base="xs:string">
			<xs:length value="5"/>
			<xs:pattern value="[0-1]{1,3}[0]*"/>
		</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="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 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_IMG" 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_IMG">
		<xs:annotation>
			<xs:documentation>MBS Antwortmessage IMG: zur Übermittlung von Images</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_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_2" 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_3" 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_4" 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 oder einem eigenen eKA-Server 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="31"/>
			<xs:whiteSpace value="collapse"/>
			<xs:pattern value="2[0-9]{15}[A-Z0-9]*"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:complexType name="PrcgType">
		<xs:sequence>
			<xs:element name="FdeOut" type="FdeOutType">
				<xs:annotation>
					<xs:documentation>Definiert die Ausblendungen die an den Images vorgenommen wurden, dargestellt durch eine Ziffernfolge [0,1]. Die Bedeutung der einzelnen Stellen ist, wie folgt:		
1 - Raster ausgeblendet		
2 - Logobereich ausgeblendet		
3 - Unterschrift ausgeblendet		
4,5 - Reserve			
Wurde eine Ausblendung vorgenommen, ist an die entsprechende Stelle eine '1' zu setzen, sonst eine '0'. '01100`steht somit für: Logo und Unterschrift sind ausgeblendet.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="DocTp" type="DocTpType" minOccurs="0">
				<xs:annotation>
					<xs:documentation>Belegart, nur wenn Raster ausgeblendet wurde, sonst nicht zu verwenden. 

Anmerkung: eine zusätzliche Kennzeichnung  "N" für Normbeleg und "A" für (Alt-)Belege ohne BelegId, wie sie in EDI vorgesehen war, entfällt. Wurde DocId kodiert ist "N" zu unterstellen, wurde DocId nicht kodiert ist "A" zutreffend</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="DocId" minOccurs="0">
				<xs:annotation>
					<xs:documentation>Beleg-Id, nur wenn Raster ausgeblendet wurde, sonst nicht zu verwenden.

Beleg-Id's der Zahlungsanweisung (in Klammer Belegart):
	006 Standard (30+), Truncation (32+)
	009 Finanzamt (30+)

Es sind nur die BelegIds der Enumeration gültig. Wenn keine BelegId vorhanden ist, ist das Feld nicht zu kodieren.</xs:documentation>
				</xs:annotation>
				<xs:complexType>
					<xs:simpleContent>
						<xs:extension base="DocIdType"/>
					</xs:simpleContent>
				</xs:complexType>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<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 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  wenn Alrt gesetzt</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>Erfolgt die Lieferung des EBZ auf Grund eines vom Kunden gesendeten
EBZ, so ist Alrt zu kodieren. andernfalls nicht zu verwenden.

War der übermittelte EBZ fehlerhaft, sodass eine Ergänzung 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. Das Feld  ist  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-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" type="BtchRefType">
				<xs:annotation>
					<xs:documentation>Inhalt des BtchCtr der Anforderungsmessage</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="RestrtDtTm" type="ISODateTime" minOccurs="0">
				<xs:annotation>
					<xs:documentation>Im Fall der Anforderung mittels RestrtDtTm oder  mittels StartDt  und kein EndDt in der IMG Request Message kodiert war, ist hier das Wiederaufsetzzeitpunkt zurück zu geben, um eine lückenlose Lieferung der Images zu gewährlsiten. Sonst nicht zu verwenden</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="RefsType_3">
		<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">
				<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 oder EbzId kodiert wird hier genau ein EBZ mittels einer FileId referenziert. 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_1">
				<xs:annotation>
					<xs:documentation>IMG definiert die Nachricht als Image-Antwort</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="Acct" type="AcctType">
				<xs:annotation>
					<xs:documentation>Zu den übertragenen Images zugehöriges Konto</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:sequence maxOccurs="unbounded">
				<xs:element name="Refs" type="RefsType_2">
					<xs:annotation>
						<xs:documentation>Referenz auf die Image-Anforderung</xs:documentation>
					</xs:annotation>
				</xs:element>
				<xs:sequence maxOccurs="unbounded">
					<xs:element name="Prcg" type="PrcgType">
						<xs:annotation>
							<xs:documentation>Beinhaltet die Bearbeitungsprozesse der übertragenen Images</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 Images als ZIP gepackt übertragen werden. Die FileID muss in ihrem Sessionanteil mit der aktuellen MBS Session übereinstimmen.

Die Images selbst sind mit ihrer Referenz aus dem CAMT (AcctSvcrRef) zu referenzieren.</xs:documentation>
						</xs:annotation>
					</xs:element>
				</xs:sequence>
				<xs:element name="RspnTxt" type="RspnTxtType" minOccurs="0" maxOccurs="unbounded">
					<xs:annotation>
						<xs:documentation>Zusatzinformation, wenn die Anforderung nicht zur Gänze erfüllt werden konnte.</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="RplyInfType_2">
		<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_3"/>
			<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 EDI Format (PAYMUL oder DIRDEB), 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, der vollständig zu übermitteln ist (d.h. es ist nicht zulässig in diesem Fall SCT oder SDD Aufträge aus einem Container zu entfernen) und in einem Antwortfile eingestellt wird.

Bei Kopien von EDI Aufträgen sind Teile der Inhalte des UNB-Segments  (und zwar UNB.S001 Syntax Indentifier und UNB0020 ICR) und die Inhalte der UNH-Segmente UNVERÄNDERT vom den Originalaufträgen zu übernehmen. Alle anderen Inhalte des UNB-Segments d.s. UNB.S002 Interchange Sender, UNB.S003 Interchange Recipient, sowie UNB.S004 Date/Time können, müssen aber nicht vom BR angepasst werden. Das UNZ-Segment ist ggf. (nur ein Teil einer Interchange wurde angefordert) anzupassen. Unabhängig von der Art der Anforderung, ist es dem BR überlassen, ob er mehrere Imterchanges (=Files) erstellt oder nur eine Interchange, in die alle angeforderten Messages eingestellt werden, sofern dies auf Grund der Anforderung (identes UNB-Segment!) möglich ist. Jedenfalls aber dürfen nur angeforderte Messages übertragen werden.</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="RplyInfType_3">
		<xs:sequence>
			<xs:element name="SubTp" type="TpType_3">
				<xs:annotation>
					<xs:documentation>Abhängig von den übertragenen Daten ist Tp entsprechend der Aufzählung zu kodieren.</xs:documentation>
				</xs:annotation>
			</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="FileIdType" 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  ISOSTA	 ISO Statusnachrichten
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_4">
		<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_3">
					<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="RspnTxtType">
		<xs:restriction base="xs:string">
			<xs:minLength value="1"/>
			<xs:maxLength value="70"/>
			<xs:whiteSpace value="collapse"/>
		</xs:restriction>
	</xs:simpleType>
	<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">
		<xs:restriction base="xs:string">
			<xs:length value="3"/>
			<xs:enumeration value="EBZ"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="TpType_1">
		<xs:restriction base="xs:string">
			<xs:length value="3"/>
			<xs:enumeration value="IMG"/>
		</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="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>
