<?xml version="1.0" encoding="UTF-8"?>
<!-- Mit XMLSpy v2011 rel. 2 (http://www.altova.com) von STUZZA (STUZZA) bearbeitet -->
<!-- edited with XMLSpy v2010 rel. 3 (http://www.altova.com) by Helmut Biely (private) -->
<xs:schema xmlns="http://www.stuzza.at/MBS/V6.0.01/Request" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" targetNamespace="http://www.stuzza.at/MBS/V6.0.01/Request" elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="xmldsig-core-schema.xsd"/>
	<!-- ********************************************************************************-->
	<!-- ***     Änderungen gegenüber Vorversion:                                   *** -->
	<!-- ***     o AcctType1 eingefügt für Message_KTO                           ***-->
	<!-- ***     o SubTpType_1 DAAB eingefügt                                         *** -->
	<!-- ***     o Kommentar zur Signatur (PK entfernt)                              *** -->
	<!-- ******************************************************************************** -->
	<!-- ***     Änderungen gegenüber Version 01.12.2011                       ***-->
	<!-- ***     o Defintion des SWIFT Konto bzw. des                                ***-->
	<!-- ***        NonDomestic Acct eingeschränkt                                      ***-->
	<!-- ******************************************************************************** -->
	<!-- ***     Änderungen gegenüber Version 15.12.2011                       ***-->
	<!-- ***     o Kommentar RequinfType3/RestrtDtTm                               ***-->
	<!-- ******************************************************************************** -->
	<!-- ***     Änderungen gegenüber Version 25.01.2012                       ***-->
	<!-- ***     o Kommentar KTO ReqInf/SartStmtNb auch Camt053          ***-->
	<!-- ***     o Kommentar KTO Hinweise zu EndDtTm und EndStmtNb   ***-->
	<!-- ***        bezüglich  lokaler DB                                                         ***-->
	<!-- ***     o Kommentar KOP ReqInf/MsgRef  ICR plus UNH  Ref.        ***-->
	<!-- ******************************************************************************** -->
	<!-- ***     Änderungen gegenüber Version 10.02.2012                       ***-->
	<!-- ***     o SubTpType_1 max Länge auf 7 erhöht                             ***-->
	<!-- ***     o SubTpType_1 zusätzlicher Wert "DEPOT" aufgenommen ***-->
	<!-- ***     o EbzID Längenangaben konsolidiert                                    ***-->
	<!-- ******************************************************************************** -->
	<!-- ***     Änderungen gegenüber Version 24.02.2012                       ***-->
	<!-- ***     o GrpHdr herausgezogen aus Teilnachrichten                    ***-->
	<!-- ***     o Teilnachrichten max. einmal; Wiederh. über ReqInf           ***-->
	<!-- ***     o Tp gestrichen, da bereits in Nachrichtenname enth.         ***-->
	<!-- ***     o BtchCtr als Zähler für die Anforderung je Typ                  ***-->
	<!-- ***     o Konsolidierung von ReqInf IMG,KTO und PDF                   ***-->
	<!-- ******************************************************************************** -->
	<!-- ***     Änderungen gegenüber Version 15.03.2012                       ***-->
	<!-- ***     o Korrektur Tippfehler auf XMLDSig und AddtlSgntrInf        ***-->
	<!-- ******************************************************************************** -->
	<!-- ***     Änderungen gegenüber Version 20.07.2012                       ***-->
	<!-- ***     o KTO-Anforderung über Auszugsnummer: Klarstellung     ***-->
	<!-- ***        zum Format der Auszugsnummer in   Start/EndStmtNbr    ***-->
	<!-- ***     o KTO-Anforderung: Komentierung der optionalen Weiche ***-->
	<!-- ***        in ReqInf erweitert, statt Einzelkommentierung je Feld      ***-->
	<!-- ******************************************************************************** -->
	<!-- ***     Änderungen gegenüber Version 14.09.2012                       ***-->
	<!-- ***     o Kommentar EBZ Anf. - keine Konvertierung auf V.6.0       ***-->
	<!-- ***     o Kommentare KOP Anf. - Ergänzung MT101, EDI Regeln    ***-->
	<!-- ***     o StmtNumType auf postiveInteger geändert                       ***-->
	<!-- ******************************************************************************** -->
	<!-- ***     Änderungen gegenüber Version 12.12.2012                       ***-->
	<!-- ***     o Änderung Kommentar zu BtchCtr in allen ReqInfTypes     ***-->
	<!-- ***     o MsgRef in KOP-Anforderung auf max. 1 reduziert           ***-->
	<!-- ******************************************************************************** -->
	<!-- ***     Änderungen gegenüber Version 20.12.2012                       ***-->
	<!-- ***     o Kommentar zur Weiche in ReqInfType_3 (Camt052)         ***-->
	<!-- ******************************************************************************** -->
	<xs:attribute name="versiondate" fixed="15.03.2013">
		<xs:annotation>
			<xs:documentation xml:lang="de">Versionsdatum dieses Schemas</xs:documentation>
		</xs:annotation>
	</xs:attribute>
	<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>Währung des Kontos</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="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="BookgDtInd">
		<xs:restriction base="xs:boolean"/>
	</xs:simpleType>
	<xs:simpleType name="BtchCtrType">
		<xs:annotation>
			<xs:documentation>Laufende Nummer des Request mit 1 beginned,  eindeutig über das gesamte Dokument. Nicht notwendiger Weise lückenlos.</xs:documentation>
		</xs:annotation>
		<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_Request_Message" type="MBS_Request_Message_Type"/>
		</xs:sequence>
	</xs:complexType>
	<xs:simpleType name="DocType">
		<xs:restriction base="xs:boolean"/>
	</xs:simpleType>
	<xs:complexType name="DspsrType">
		<xs:sequence>
			<xs:element name="DspsrNm">
				<xs:annotation>
					<xs:documentation>Name des signierenden Verfügers.</xs:documentation>
				</xs:annotation>
				<xs:simpleType>
					<xs:restriction base="Max35Text"/>
				</xs:simpleType>
			</xs:element>
			<xs:element name="DspsrNbr" type="DspsrNbrType">
				<xs:annotation>
					<xs:documentation>Zugehörige Verfügernummer </xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:simpleType name="DspsrNbrType">
		<xs:restriction base="Max17Text">
			<xs:pattern value="[A-Z0-9\-]*"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="DtType">
		<xs:restriction base="xs:date"/>
	</xs:simpleType>
	<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="GrpHdrType">
		<xs:sequence>
			<xs:element name="MsgId" type="MsgIdType">
				<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: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="IndCmpType">
		<xs:restriction base="xs:boolean"/>
	</xs:simpleType>
	<xs:simpleType name="ImgType">
		<xs:restriction base="xs:boolean"/>
	</xs:simpleType>
	<xs:simpleType name="ISODateTime">
		<xs:restriction base="xs:dateTime"/>
	</xs:simpleType>
	<xs:simpleType name="ImgTpType">
		<xs:restriction base="xs:string">
			<xs:enumeration value="EER"/>
			<xs:enumeration value="BMR"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Max4Text">
		<xs:restriction base="xs:string">
			<xs:minLength value="1"/>
			<xs:maxLength value="4"/>
			<xs:whiteSpace value="collapse"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Max17Text">
		<xs:restriction base="xs:string">
			<xs:minLength value="1"/>
			<xs:maxLength value="17"/>
			<xs:whiteSpace value="collapse"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Max34Text">
		<xs:restriction base="xs:string">
			<xs:minLength value="1"/>
			<xs:maxLength value="34"/>
			<xs:whiteSpace value="collapse"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Max35Text">
		<xs:restriction base="xs:string">
			<xs:minLength value="1"/>
			<xs:maxLength value="35"/>
			<xs:whiteSpace value="collapse"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="Max70Text">
		<xs:restriction base="xs:string">
			<xs:minLength value="1"/>
			<xs:maxLength value="70"/>
			<xs:whiteSpace value="collapse"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:complexType name="MBS_Request_Message_Type">
		<xs:sequence>
			<xs:element name="GrpHdr" type="GrpHdrType"/>
			<xs:element ref="MBS_Request_Message_EBZ" minOccurs="0">
				<xs:annotation>
					<xs:documentation>MBS Anforderungsmessage EBZ für die Anforderung von einem oder mehreren EBZ.

Ein eBZ der MBS V.6.0 oder höher kann nicht von einem PC Paket der Version 5.x angefordert werden. Ebenso darf an einen V.6.0 Client nur ein EBZ der V.6.0 geliefert werden. Eine Konvertierung von EBZ der V.5.x ist nicht vorgesehen.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element ref="MBS_Request_Message_IMG" minOccurs="0">
				<xs:annotation>
					<xs:documentation>MBS Anforderungsmessage IMG für die Anforderungen von einem oder mehrerren Images</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element ref="MBS_Request_Message_KOP" minOccurs="0">
				<xs:annotation>
					<xs:documentation>MBS Anforderungsmessage KOP für die Anforderung von Auftragskopien
 (EDI, XML oder MT101).</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element ref="MBS_Request_Message_KTO" minOccurs="0">
				<xs:annotation>
					<xs:documentation>MBS Anforderungsmessage KTO für die Anforderungen von Kontoinformationen, die in SubTp spezifiziert sind. wie z.B. Auszüge, Belege, Retourdatenträger und ISO-Statusmessages</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element ref="MBS_Request_Message_PDF" minOccurs="0">
				<xs:annotation>
					<xs:documentation>MBS Anforderungsmessage PDF für die Anforderung elektronischer Kontoauszüge im PDF-Format (eKA) . </xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="XMLDSig">
				<xs:annotation>
					<xs:documentation>Die Anforderung ist mittels XMLDSig (PIN des anfordernden Verfügers ) zu autorisieren.

Die XMLDSig erstreckt sich dabei über alle vorangehenden Sub-Messages (EBZ, IMG, KOP, etc.)  bis AddtlSgntrInf.</xs:documentation>
				</xs:annotation>
				<xs:complexType>
					<xs:sequence>
						<xs:element name="AddtlSgntrInf" type="SgntrInfType">
							<xs:annotation>
								<xs:documentation>Zusatzinformationen zur Signatur, diie mit zu signieren sind.</xs:documentation>
							</xs:annotation>
						</xs:element>
						<xs:element ref="ds:Signature"/>
					</xs:sequence>
				</xs:complexType>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:element name="MBS_Request_Message_EBZ">
		<xs:annotation>
			<xs:documentation>MBS Anforderungsmessage EBZ: 
Anforderung von EBZ

Ein eBZ der MBS V.6.0 oder höher kann nicht von einem PC Paket der Version 5.x angefordert werden. Ebenso darf an einen V.6.0 Client nur ein EBZ der V.6.0 geliefert werden. Eine Konvertierung von EBZ der V.5.x ist nicht vorgesehen.</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="ReqInf" type="ReqInfType" maxOccurs="unbounded">
					<xs:annotation>
						<xs:documentation>Eine EBZ –Anforderung kann entweder über die Angabe einer Identifikationsnummer eines EBZ (TpEbz) oder über einen, dem EBZ zugeordneten Verfüger (TpVerf) erfolgen.</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
	<xs:element name="MBS_Request_Message_IMG">
		<xs:annotation>
			<xs:documentation>MBS Anforderungsmessage IMG: 
Anforderungen von Images</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="ReqInf" type="ReqInfType_1" maxOccurs="unbounded">
					<xs:annotation>
						<xs:documentation>Ein oder mehrere Anfragen </xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
	<xs:element name="MBS_Request_Message_KOP">
		<xs:annotation>
			<xs:documentation>MBS Anforderungsmessage KOP: 
Anforderung von Auftragskopien
 (EDI, XMLoder MT101).</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="ReqInf" type="ReqInfType_2" maxOccurs="unbounded">
					<xs:annotation>
						<xs:documentation>Werden  sensitive Auftragsbestände (z.B. Gehaltsdaten) als Kopie angefordert, so kann der BR die Anforderung mit Status 745 ablehnen.</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
	<xs:element name="MBS_Request_Message_KTO">
		<xs:annotation>
			<xs:documentation>MBS Anforderungsmessage KTO: 
Anforderungen von Auszügen, Belegen, Retourdatenträger und ISO-Statusmessages.

Die Art der gewünschten Kontoinformation wird in SubTp spezifiziert.</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="ReqInf" type="ReqInfType_3" maxOccurs="unbounded">
					<xs:annotation>
						<xs:documentation>Ein oder mehrere Anfragen  unterschiedlichen Subtyps</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
	<xs:element name="MBS_Request_Message_PDF">
		<xs:annotation>
			<xs:documentation>MBS Anforderungsmessage PDF: 
Anforderung von PDF Auszügen
</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="ReqInf" type="ReqInfType_4" maxOccurs="unbounded">
					<xs:annotation>
						<xs:documentation>Spezifikation der konkreten Anforderung der PDF Auszüge optional ergänzt mit Belegen und/oder Images, Signatur etc.

Sämtliche Anforderungsarten sind optional in dem Sinne, dass es kein definiertes Mindestprofil gibt, das von allen Bankrechnern unterstützt werden muss. Nicht unterstützte Optionen sind vom Bankrechner mit Status 700 "Anforderung nicht unterstützt" abzulehnen.

Werden auf Wunsch für einen Bankrechner Defaultwerte für die Attribute zu ReqInf eingestellt, so sind diese so zu gestalten, dass sie vom Kunden bewusst überschrieben werden können, auch auf die Gefahr hin, dass die Kundenwahl dann zu einer Ablehnung mangels Unterstützung führt.</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
	<xs:simpleType name="MsgIdType">
		<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:simpleType name="MsgRefType">
		<xs:restriction base="Max35Text"/>
	</xs:simpleType>
	<xs:complexType name="ReqInfType">
		<xs:sequence>
			<xs:element name="BtchCtr" type="BtchCtrType">
				<xs:annotation>
					<xs:documentation>Laufende Nummer des Request mit 1 beginned anlässlich des ersten Vorkommens des BtchCtrType,  eindeutig über das gesamte Dokument, also über alle Requesttypen hinweg. Nicht notwendiger Weise lückenlos; wichtig ist die Eindeutigkeit innerhalb der MsgId zwecks späterer Referenzierung.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:choice>
				<xs:element name="TpEbz" type="TpEbzType">
					<xs:annotation>
						<xs:documentation>Anforderung von konkreten 
EBZ über Id-nummer</xs:documentation>
					</xs:annotation>
				</xs:element>
				<xs:element name="TpVerf" type="TpVerfType">
					<xs:annotation>
						<xs:documentation>Anforderung von EBZ über Verfüger. Die zutreffende Verfügernummer ist der Autorisierung zu entnehmen.</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:choice>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="ReqInfType_1">
		<xs:sequence>
			<xs:element name="BtchCtr" type="BtchCtrType">
				<xs:annotation>
					<xs:documentation>Laufende Nummer des Request mit 1 beginned anlässlich des ersten Vorkommens des BtchCtrType,  eindeutig über das gesamte Dokument, also über alle Requesttypen hinweg. Nicht notwendiger Weise lückenlos; wichtig ist die Eindeutigkeit innerhalb der MsgId zwecks späterer Referenzierung.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="Acct" type="AcctType">
				<xs:annotation>
					<xs:documentation>Acct definiert das Konto, zu dem Images angefortet werden.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:choice>
				<xs:element name="RefNum">
					<xs:annotation>
						<xs:documentation>In RefNum ist die Imagereferenz einzustellen, die entsprechend dem Attribut ImgTp als Einzel- oder Mehrfachreferenz zu interpretieren ist.
Wurde ImgTp nicht kodiert, ist RefNum als Einzelreferenz zu interpretieren</xs:documentation>
					</xs:annotation>
					<xs:complexType>
						<xs:simpleContent>
							<xs:extension base="Max35Text">
								<xs:attribute name="ImgTp" type="ImgTpType" default="EER">
									<xs:annotation>
										<xs:documentation>Das Attribut ImgTp ist nur dann zun kodieren, wenn eine Anforderung mittels Imagereferenz (RefNum) erfolgt.  Andernfalls ist die Anforderung mit negativem Status 708 abzulehnen.
EER ist zu kodieren, wenn es sich um eine Einzelreferenz (Ersterfassungsreferenz oder bankindividuelle Referenznummer) handelt und ist nur im Falle einer Einzelgutschrift zulässig.
BMR ist zu kodieren, wenn es sich um eine Mehrfachreferenz handelt und ist nur im Falle einer Sammelgutschrift zulässig; die Anzahl der Images muß nicht der Anzahl der Einzelumsätze der Sammelgutschrift entsprechen, da nicht zu jedem Umsatz ein Image vorhanden sein muß.

Die Angabe der Referenz erfolgt im CAMT im Feld AcctSvcrRef.</xs:documentation>
									</xs:annotation>
								</xs:attribute>
							</xs:extension>
						</xs:simpleContent>
					</xs:complexType>
				</xs:element>
				<xs:sequence>
					<xs:element name="StartDt" type="DtType">
						<xs:annotation>
							<xs:documentation>Sollen Images unter Angabe des Buchungsdatums der zugehörigen Auszüge geliefert werden, so ist in StartDt das Beginndatum anzugeben, ab dem die zu den Auszügen zugehörigen Images zu liefern sind.

Ist neben StartDt auch ein EndDt kodiert, so werden die in SubTp angegebenen  Kontoinformationen für das damit definierte Zeitfenster angefordert.

Ein in der Zukunft liegendes Anforderungsdatum ist unzulässig und wird vom Bankrechner abgelehnt. </xs:documentation>
						</xs:annotation>
					</xs:element>
					<xs:element name="EndDt" type="DtType" minOccurs="0">
						<xs:annotation>
							<xs:documentation>Die optionale Angabe von EndDt erlaubt die Lieferung von Images zu den Auszügen einer definierten Kalenderperiode.

Wird EndDt nicht kodiert, so sind die Images von StartDt bis zum aktuellen Tagesdatum zu liefern.</xs:documentation>
						</xs:annotation>
					</xs:element>
				</xs:sequence>
				<xs:sequence>
					<xs:element name="StartStmtNb" type="StmtNumType">
						<xs:annotation>
							<xs:documentation>Sollen Images zu einem konkreten Auszug, oder einer Folge von Auszügen angeliefert werden, so ist in StartStmtNb die erste Auszugsnummer anzugeben, zu der Images zu liefern sind</xs:documentation>
						</xs:annotation>
					</xs:element>
					<xs:element name="EndStmtNb" type="StmtNumType" minOccurs="0">
						<xs:annotation>
							<xs:documentation>Mit EndStmtNb kann die Anforderung von Images bis zu einer bestimmten Auszugsnummer begrenzt werden. EndStmtNb muss größer oder gleich der in StartStmtNb angebenen Auszugsnummer sein, andernfalls ist mit negativen Status 708 zu reagieren.

Wird EndStmtNb nicht kodiert, so sind die  Images bis zu der aktuell höchsten Auszugsnummer  zu liefern.
</xs:documentation>
						</xs:annotation>
					</xs:element>
				</xs:sequence>
				<xs:element name="RestrtDtTm" type="ISODateTime">
					<xs:annotation>
						<xs:documentation>Soll eine lückenlose Lieferung von Images sicher gestellt werden (z.B. zugleich mit den zugehörigen Auszügen), ist in RestrtDtTm das vom BR empfangene Wiederaufsetzdatum anzugeben.</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:choice>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="ReqInfType_2">
		<xs:sequence>
			<xs:element name="BtchCtr" type="BtchCtrType">
				<xs:annotation>
					<xs:documentation>Laufende Nummer des Request mit 1 beginned anlässlich des ersten Vorkommens des BtchCtrType,  eindeutig über das gesamte Dokument, also über alle Requesttypen hinweg. Nicht notwendiger Weise lückenlos; wichtig ist die Eindeutigkeit innerhalb der MsgId zwecks späterer Referenzierung.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="EbzId">
				<xs:annotation>
					<xs:documentation>In EbzId ist die Identifikationsnummer jenes EBZ einzustellen, dessen Datenträger als Kopie angefordert werden. 
Ist EbzId das einzige Element der Anforderung, werden alle Datenträger (EDI, XML und MT101) dieses EBZ als Kopie angefordert.</xs:documentation>
				</xs:annotation>
				<xs:simpleType>
					<xs:restriction base="EbzIdType"/>
				</xs:simpleType>
			</xs:element>
			<xs:element name="MsgRef" type="MsgRefType" minOccurs="0">
				<xs:annotation>
					<xs:documentation>Mittels MsgRef wird die Anforderung auf die Kopie eines einzigen Datenträgers aus dem vorangehend definierten EBZ eingeschränkt.
In MsgRef ist dafür die Referenznummer aus Ref des SctnHdr des EBZ einzustellen. (Diese ist ident mit der MsgId des GrpHdr des zugehörigen XML-Datenträgers bzw. in Fall eines EDI Datenträgers mit ICR plus der Messagereferenz des UNH-Segments, wobei die beiden Referenzen aus UNB und UNH Segment mit Schrägstrich zu trennen sind. Im Fall eines MT101 ist die MsgRef dem Feld20 zu entnehmen).
Sollen mehrere DT aus einem EBZ in Kopie angefordert werden, ist ReqInf zu wiederholen; damit ist auch eine eindeutige Referenzierung im Fall einer Statusantwort möglich, falls eine Kopie nicht erstellt werden kann.
</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="ReqInfType_3">
		<xs:sequence>
			<xs:element name="BtchCtr" type="BtchCtrType">
				<xs:annotation>
					<xs:documentation>Laufende Nummer des Request mit 1 beginned anlässlich des ersten Vorkommens des BtchCtrType,  eindeutig über das gesamte Dokument, also über alle Requesttypen hinweg. Nicht notwendiger Weise lückenlos; wichtig ist die Eindeutigkeit innerhalb der MsgId zwecks späterer Referenzierung.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="SubTp">
				<xs:annotation>
					<xs:documentation>Mit SubTp wird die eigentliche Art der angeforderten Kontoinformation festgelegt:
o MT940  SWIFT MT940 Kontoauszüge
o MT941  SWIFT MT941 Kontostandsinformationen
o MT942  SWIFT MT942 Kontovormerkungen
o BELEG	Belegdaten zu MT940 Kontoauszügen
o DAAB  Informationen zu Daueraufträgen
o DEPOT Auszug eines WP Depots
o CREMUL Retourdatenträger im EDI
o DEBMUL Retourdatenträger im EDI
o CAMTnnn Kontoinformationen  ISO camt052, camt053 oder camt054
o ISOSTS Statusnachricht im Format ISO 20022  Payment Status Report
</xs:documentation>
				</xs:annotation>
				<xs:simpleType>
					<xs:restriction base="SubTpType_1">
						<xs:maxLength value="7"/>
					</xs:restriction>
				</xs:simpleType>
			</xs:element>
			<xs:element name="Acct" type="AcctType1">
				<xs:annotation>
					<xs:documentation>Acct definiert das Konto, zu dem die Kontoinformationen gemäß SubTp angefordet werden.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:choice minOccurs="0">
				<xs:annotation>
					<xs:documentation>Ist für Tp=MT941, MT942 oder ISOSTAT nicht zu verwenden.

Für Tp=Camt052 kann ein Wiederaufsetzdatum optional kodiert werden. Es ist jedoch nur für BR relevant, die einen inkrementellen Camt052 (siehe die Einführungsdokumentation) anbieten; sonst zu ignorieren. Alle anderen Sub-Felder dieser Weiche sind für Camt052 nicht zulässig.</xs:documentation>
				</xs:annotation>
				<xs:sequence>
					<xs:element name="StartDt" type="DtType">
						<xs:annotation>
							<xs:documentation>Mit StartDt wird das Beginndatum i.e. das Buchungsdatum, ab dem die gewünschten Informationen zu liefern sind, definiert.

Ist neben StartDt auch ein EndDt kodiert, so werden die in SubTp angegebenen  Kontoinformationen für das damit definierte Zeitfenster angefordert.

Ein in der Zukunft liegendes Anforderungsdatum ist unzulässig und wird vom Bankrechner abgelehnt. </xs:documentation>
						</xs:annotation>
					</xs:element>
					<xs:element name="EndDt" type="DtType" minOccurs="0">
						<xs:annotation>
							<xs:documentation>Bezieht  sich die Anforderung auf  einen konkreten Zeitraum, definiert EndDt das Ende des gewünschten Zeitfensters. EndDt muss größer oder gleich der in StartDt kodierten Darumsangabe sein, andernfalls ist mit negativen Status 708 zu reagieren. Aber Achtung: beim Eintragen in die lokale DB des Client dürfen eventuell vorhandene Einträge die hinter diesem Datum liegen nicht überschrieben werden.

Wird EndDt nicht kodiert, so sind alle Informationen von StartDt bis zum aktuellen Tagesdatum zu liefern.</xs:documentation>
						</xs:annotation>
					</xs:element>
				</xs:sequence>
				<xs:sequence>
					<xs:element name="StartStmtNb" type="StmtNumType">
						<xs:annotation>
							<xs:documentation>Mit StartStmtNb können Kontoinformationen alternativ zur Datumsangabe mittels Angabe der Auszugsnummer im Format JJJJNNNNN (z.B. 201200034) angefordert werden.
StartStmtNb ist nur für SubTp = Camt053, MT940 und BELEG zulässig. In allen anderen Fällen ist mit negativen Status 708 zu antworten. 
</xs:documentation>
						</xs:annotation>
					</xs:element>
					<xs:element name="EndStmtNb" type="StmtNumType" minOccurs="0">
						<xs:annotation>
							<xs:documentation>Mit EndStmtNb (Format siehe StartStmtNb) kann die Anforderung von Kontoinformationen bis zu einer bestimmten Auszugsnummer begrenzt werden. EndStmtNb muss größer oder gleich der in StartStmtNb angebenen Auszugsnummer sein, andernfalls ist mit negativen Status 708 zu reagieren. Aber Achtung: beim Eintragen in die lokale DB des Client dürfen eventuell vorhandene Einträge die hinter dieser Auszugsnummer liegen nicht überschrieben werden.

Wird EndStmtNb nicht kodiert, so sind die angeforderten Kontoinformationen bis zu der aktuell höchsten Auszugsnummer  zu liefern.
</xs:documentation>
						</xs:annotation>
					</xs:element>
				</xs:sequence>
				<xs:element name="RestrtDtTm" type="ISODateTime">
					<xs:annotation>
						<xs:documentation>RstrtDtTm dient der Angabe einer Wiederaufsetzreferenz, um eine lückenlose Information (Kontoauszugsdaten, Belegdaten, etc.) sicher zu stellen. Für die Erstanforderung, sofern vom Kunden nicht vorgegeben, sind maximal die letzten 14 Tage anzufordern. 
Ein in der Zukunft liegendes Anforderungsdatum ist unzulässig und wird vom Bankrechner abgelehnt. 

Für MT940, Belegdaten und Images ist die Wiederaufsetzreferenz dem Feld RstrtDtTm der letzten  Anzwortnachricht zu entnehmen.  Im Fall von EDI Retourdatenträger ist das jeweils höchste empfangene Referenzdatum  (DTM.C507.2380 der Segmentgruppe 1) als neues Wiederaufsetzdatum heranzuziehen, da nicht davon ausgegangen wird, daß in einem Filetransfer übertragene mehrfache EDI-Retourdatenträger jeweils nach dem Erstellungsdatum sortiert übermittelt werden.
Im Fall von XML Kontoinformationen (CAMT Nachrichten) ist die Wiederaufsatzreferenz  dem höchsten Wert von ToDtTm gleich zu setzen. 

RestrtDtTm ist nur für die  Anforderungsarten SubTP = MT940, BELEG, CREMUL DEBMUL oder CAMTS gültig., </xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:choice>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="ReqInfType_4">
		<xs:sequence>
			<xs:element name="BtchCtr" type="BtchCtrType">
				<xs:annotation>
					<xs:documentation>Laufende Nummer des Request mit 1 beginned anlässlich des ersten Vorkommens des BtchCtrType,  eindeutig über das gesamte Dokument, also über alle Requesttypen hinweg. Nicht notwendiger Weise lückenlos; wichtig ist die Eindeutigkeit innerhalb der MsgId zwecks späterer Referenzierung.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="Acct" type="AcctType">
				<xs:annotation>
					<xs:documentation>Acct definiert das Konto, zu dem die eKA angefortet werden.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:choice>
				<xs:sequence>
					<xs:element name="StartDt" type="DtType">
						<xs:annotation>
							<xs:documentation>Mit StartDt wird das Buchungsdatum definiert, ab der die PDF-Kontoinformationen zu liefern sind.

Ein in der Zukunft liegendes Anforderungsdatum ist unzulässig und wird vom Bankrechner abgelehnt. </xs:documentation>
						</xs:annotation>
					</xs:element>
					<xs:element name="EndDt" type="DtType" minOccurs="0">
						<xs:annotation>
							<xs:documentation>Bezieht  sich die Anforderung auf  einen konkreten Zeitraum, definiert EndDt das Ende des gewünschten Zeitfensters.

Wird EndDt nicht kodiert, sind alle Informationen von StartDt bis zum aktuellen Tagesdatum zu liefern.  
</xs:documentation>
						</xs:annotation>
					</xs:element>
				</xs:sequence>
				<xs:sequence>
					<xs:element name="StartStmtNb" type="StmtNumType">
						<xs:annotation>
							<xs:documentation>Mit StartStmtNb wird die Auszugsnummer definiert, ab der die PDF-Kontoinformationen zu liefern sind.</xs:documentation>
						</xs:annotation>
					</xs:element>
					<xs:element name="EndStmtNb" type="StmtNumType" minOccurs="0">
						<xs:annotation>
							<xs:documentation>Mit EndStmtNb kann die Anforderung von PDF-Kontoinformationen bis zu einer bestimmten Auszugsnummer begrenzt werden. EndStmtNb muss größer oder gleich der in StartStmtNb angebenen Auszugsnummer sein, andernfalls ist mit negativen Status 708 zu reagieren.

Wird EndStmtNb nicht kodiert, so sind die angeforderten PDF-Kontoinformationen bis zu der aktuell höchsten Auszugsnummer  zu liefern.</xs:documentation>
						</xs:annotation>
					</xs:element>
				</xs:sequence>
				<xs:element name="RestrtDtTm" type="ISODateTime">
					<xs:annotation>
						<xs:documentation>Mit RestrtDtTm wird eine Wiederaufsetzreferenz für eine lückenlose Übertragung der angeforderten PDF-Kontoinformationen angegeben.
Mit IndCmpltn kann optional der Abschluss des aktuellen Auszugs ausgelöst werden.

Die Wiederaufsetzereferenz ist der Antwortmessage dem jeweiligen Attribut RestrtDtTm zu entnehmen.

Abhängig vom BR (z.B. ARZ)  kann es zu Lücken in den angelieferten eKA kommen und zwar dann, wenn die Abholung intermittierend elektronisch und am KAD erfolgt 
</xs:documentation>
					</xs:annotation>
				</xs:element>
			</xs:choice>
		</xs:sequence>
		<xs:attribute name="Doc" type="DocType" default="false">
			<xs:annotation>
				<xs:documentation>Sollen zusätzlich zu den Auszügen auch die zugehörigen Belege geliefert werden, so ist der Wert auf 'true' zu setzen.</xs:documentation>
			</xs:annotation>
		</xs:attribute>
		<xs:attribute name="Img" type="ImgType" default="false">
			<xs:annotation>
				<xs:documentation>Sollen zusätzlich zu den Auszügen auch die zugehörigen Images geliefert werden, so ist der Wert auf 'true' zu setzen.</xs:documentation>
			</xs:annotation>
		</xs:attribute>
		<xs:attribute name="Sgntr" type="SgntrType" default="false">
			<xs:annotation>
				<xs:documentation>Ist Sgntr=true so ist der PDF Auszug elektronisch 
zu signieren.

Wird von einem BR Sgntr nicht unterstützt, ist mit Status 700 zu antworten.</xs:documentation>
			</xs:annotation>
		</xs:attribute>
		<xs:attribute name="IndCmpltn" type="IndCmpType" default="false">
			<xs:annotation>
				<xs:documentation>Mit IndCmpltn wird angezeigt, ob bei erfolgreicher Lieferung der PDF Auszüge der aktuelle Kontoauszug abzuschliessen ist (true) oder nicht (false). 

IndCmpltn darf nur kodiert werden, wenn die Anforderung mittels RestrtDtTm erfolgt, andernfalls ist mit negativen Status 708 "Anforderung fehlerhaft"  zu reagieren.

Wird von einem Institut IndCmpltn nicht unterstützt, ist mit Status 700 zu antworten.</xs:documentation>
			</xs:annotation>
		</xs:attribute>
	</xs:complexType>
	<xs:simpleType name="SgntrType">
		<xs:restriction base="xs:boolean"/>
	</xs:simpleType>
	<xs:complexType name="SgntrInfType">
		<xs:sequence>
			<xs:element name="Dspsr" type="DspsrType"/>
		</xs:sequence>
	</xs:complexType>
	<xs:simpleType name="StmtNumType">
		<xs:restriction base="xs:positiveInteger">
			<xs:totalDigits value="9"/>
			<xs:pattern value="[1-2]{1,1}[0-9]{3,3}[0-9]*"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="SubTpType">
		<xs:restriction base="xs:string">
			<xs:enumeration value="alle_offen"/>
			<xs:enumeration value="hatte_Rolle"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="SubTpType_1">
		<xs:restriction base="xs:string">
			<xs:minLength value="4"/>
			<xs:maxLength value="7"/>
			<xs:enumeration value="MT940"/>
			<xs:enumeration value="MT941"/>
			<xs:enumeration value="MT942"/>
			<xs:enumeration value="BELEG"/>
			<xs:enumeration value="DAAB"/>
			<xs:enumeration value="DEPOT"/>
			<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: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:complexType name="TpEbzType">
		<xs:sequence>
			<xs:element name="EbzId" type="EbzIdType">
				<xs:annotation>
					<xs:documentation>Im Fall der TpEbz Message, wenn sich also die Anforderung auf (ein oder mehrere) konkrete Begleitzettel bezieht, wird hier die Identifikationsnummer des anzufordernden eBZ eingestellt. Das Element ist beliebig wiederholbar, sodass mehrere EBZ angefordert werden können.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="RestrtDtTm" type="ISODateTime" minOccurs="0">
				<xs:annotation>
					<xs:documentation>Soll  sicher gestellt werden dass nur EBZ geliefert werden, wenn sich der EBZ verändert hat,  ist in RestrtDtTm das vom BR zuletzt, anlässlich selber Anforderung  empfangene Wiederaufsetzdatum anzugeben.</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="4"/>
			<xs:enumeration value="COPY"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="TpType_3">
		<xs:restriction base="xs:string">
			<xs:length value="3"/>
			<xs:enumeration value="KTO"/>
		</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:complexType name="TpVerfType">
		<xs:sequence>
			<xs:element name="Acct" type="AcctType" minOccurs="0">
				<xs:annotation>
					<xs:documentation>Acct definiert das Konto, zu dem EBZ angefortet werden. Wird kein Acct angegeben, so sind alle EBZ entsprechend der Kriterien des Attribut SubTp zu liefern.

Da das TpVerf Element beliebig wiederholbar ist, können  beliebige Kombinationen von Rollen und Kontonummern in einer Anforderungsnachricht kodiert werden.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="RestrtDtTm" type="ISODateTime" minOccurs="0">
				<xs:annotation>
					<xs:documentation>Soll  sicher gestellt werden dass nur EBZ geliefert werden, wenn sich  EBZ verändert haben,  ist in RestrtDtTm das vom BR zuletzt, anlässlich selber Anforderung  empfangene Wiederaufsetzdatum anzugeben.</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
		<xs:attribute name="SubTp" type="SubTpType" use="required">
			<xs:annotation>
				<xs:documentation>Im Fall der TpVerf Message, in der also die Rolle des anfordernden Verfügers die Auswahl der EBZ bestimmt, sind die folgenden Untertypen zu  unterscheiden. 
	alle_offen 	Alle EBZ mit zum anfordernden Verfüger offenen  Aufträgen sollen geliefert werden. Offen heißt, dass der gegenständliche Verfüger noch nicht gezeichnet und eine Zeichnungsberechtigung zu noch nicht vollständig gezeichneten Aufträgen und deren Auftraggeberkonto inne hat. Enthält ein EBZ Aufträge mit FF-Indikator zu nicht vollständig gezeichneten Beständen, so handelt es sich nicht um offene Aufträge im Sinne der Anfrage. D.h. der anfordernde Verfüger muss die Möglichkeit haben, durch eine von ihm ggf. getätigte zusätzliche Zeichnung den Status von zumindest einem Bestand des EBZ zu verändern. Bei den Stausindikatoren OK, VO und FF ist dies jedoch gs. nicht der Fall. 
	hatte_Rolle	Alle eBZ der letzten 28 Tage in denen der anfordernde Verfüger eine Rolle spielte sollen geliefert werden, wobei der Begriff "Rolle" weitgehend zu sehen  ist und Ersteller eines eBZ, Erst-/Zweitzeichner, sendender Verfüger umfasst.
Die Verfügernummer des anfordernden Verfügers ist der XML-DSig zu entnehmen</xs:documentation>
			</xs:annotation>
		</xs:attribute>
	</xs:complexType>
</xs:schema>
