B2Bws Manual
Landsbankinn | November 2007 | 2 nd edition Upplýsingatæknisvið B2Bws Manual
B2Bws is a web service based on a collective standard which the Icelandic banks (Landsbanki, Kaupthing, Glitnir and Saving Banks (Sparisjóðir)) have decided on. Its purpose is to enable firms to connect their business systems directly to the service system of the bank. B2Bws should be of use to all firms of all sizes.
Landsbankinn Fyrirtækjabanki | Austurstræti 11 | 155 Reykjavík Sími 410 9191 | [email protected]
Table of Contents
B2BWS MANUAL ...... 2 TABLE OF CONTENTS ...... 4 INTRODUCTION ...... 6 Welcome ...... 6 About the document ...... 6 Prior versions ...... 6 Overview ...... 7 TECHNICAL INFORMATION ...... 8 Notice ...... 8 Communication protocols and Security ...... 8 Connecting to the B2Bws ...... 8 Timestamps ...... 8 UserNameToken ...... 9 A sample of a security header ...... 9 Signing messages ...... 9 SECURITY IN B2BWS ...... 10 Certificate ...... 10 ICELANDICONLINEPAYMENTS ...... 11 Payment(DoPayment) ...... 11 Out ...... 12 In ...... 13 ABGiro ...... 14 CGiro ...... 14 PaymentSlip ...... 14 Transfer ...... 15 Receipt ...... 16 PaymentsResult (DoPaymentResponse) ...... 17 Success ...... 17 PaymentSlip (in Success)...... 18 Errors ...... 19 Error ...... 19 Payments (DoPayments) ...... 20 Payment query (GetPaymentResult) ...... 21 PaymentsResult ...... 21 Payments query (GetPaymentsResult) ...... 21 ICELANDICONLINESTATEMENTS ...... 22 AccountStatement (GetAccountStatement) ...... 22 Get AccountStatementResponse: ...... 23 Transactions ...... 24 CurrencyRateRequest ...... 25 Currency rate (CurrencyRateResponse) ...... 25 ICELANDICONLINECLAIMS ...... 26 Claim creation / Claim modification (CreateClaims / AlterClaims) ...... 26 ClaimKey ...... 27 NoticeAndPaymentFee ...... 27 CancelClaims ...... 28 GetClaimOperationResult ...... 29
4
QueryClaims ...... 31 DefaultCharge ...... 33 DefaultInterest ...... 33 Currency information ...... 34 Discount ...... 35 Bill Presentment System ...... 36 Printing ...... 37 CreateClaim/AlterClaim ...... 38 ClaimOperationResult...... 39 CancelClaim ...... 40 ClaimQuery ...... 41 QueryPayments ...... 43 ICELANDICONLINESECONDARY COLLECTIONCLAIMS ...... 46 SecondaryCollectionPaymentsQuery ...... 46 QueryClaims ...... 47 AlterClaim(s) ...... 47 SecondaryCollectionClaimsQuery ...... 47 Claim return (SecondaryCollectionReturnClaim) ...... 47 ERROR MESSAGES ...... 48 General ...... 48 Exceptions ...... 48 SCHEMAS ...... 49 MEMOS ...... 51
5
Introduction
Welcome The most probable reason why you are reading this manual is either you already have B2B web- service or you are contemplating getting it. Either way we hope that this manual will answer your questions and explain the service in sufficient detail.
If you need any further assistance do not hesitate to use our free B2Bws consultancy service through [email protected] .
Corporate Internet Bank Tel +354 410 9191
About the document This manual is the 2 nd version since August 2007 and is for users of the web services for the banking institutions. There is another one specially for the classic B2B service, whereas their servicesupply is dissimilar in certain ways. The services described here are valid with all the banks, i.e. the same schemas and objects apply with all the banks.
The paper describes the operations that can be performed in the first version of this standard. The operations are described in a manner of the way they are N O T E performed, i.e. that each operation is described in a way that depicts all the This document contains dia- factors that need to be taken into consideration while performing each operat- grams of most of the schemas ion. used. Solid lines indicate values that must be included in the Scattered around the paper you’ll find Notes , Usercases and Nice to know schema while broken lines indi- boxes. The margins are willingly kept in desirable width to enable comment cate areas that may be left out. writing. Backmost you will find a Memo section. Please note that the schemas themselves include further Pictures are used to further explain how objects are connected within each documentation and definitions operation. Solid lines in these pictures indicate that the element in question of legitimate values. A list of must be entered, but the dotted lines indicate that the element is optional. schemas is provided at the end of the document.
Prior versions 1. version | Published August 2007
6
Overview The B2B (Business to Bank) term used in this document refers to digital transactions and requests between companies and Landsbanki Íslands. B2B transactions which take place between Lands- banki and other companies are directed through a webserver which is owned and operated by Landsbanki Íslands. When the webserver recieves a request in the form of a XML message using the SOAP protocol is forwarded to a server. The relevant server then forwards the reply message (using SOAP protocol) to the webserver which returns the reply to the original user.
The following is a high level diagram of how a client will communicate with a server which hosts the web service, which then communicates with its back office systems.
Client Client System
WS Proxy
HTTPS over TCP/IP
Firewall
Internet
Firewall
WebServer
Web Service
Reiknistofa Backend (Clearing System house)
MAKING HISTORY
Landsbanki began offering business-to-business (B2B) service in 2002, and within a few years, several hundred companies had joined the user group. A turning point occurred in 2007, when banks and savings banks agreed to offer a single XML standard featuring co-ordinated presentation of the most common operations. This enables companies to engage in XML communications with a number of banks in the most economical way possible. The classic B2B standard will continue to be in full use at Landsbanki, and it will be developed in tandem with the interbank standard, as it contains specialised banking solutions in addition to the primary services.7
Technical information
Notice As further discussed in this manual, the B2B webservice deals with standards in transfer and dissemination of data. Still, note that business logic may vary between banks. An example of ! such incident is the handling of Secondary Collection Claims.
If in any doubt of the business logic, please consult with our B2B specialists via [email protected] or contact our Corporate Service Desk in +354 410 9191.
Communication protocols and Security The B2B webservices are implemented as SOAP Web Services, accessible over the Internet through the HTTP secured with SSL (HTTPS) and Web Service Security (WSS) using the Username token and the X509 certificate token profiles.
Connecting to the B2Bws The prerequisites for access to the B2B webservice of Landsbanki are that the corporate cust- omer needs to be a registered customer of Landsbanki’s Corporate Internet Bank , abbr. CIB (i. Fyrirtækjabanki Landsbankans) and have a signed contract accepting the terms for B2B webserv- ice. In order to get access to the services you will have to add them as a web referance in your dev environment https://b2bws.fbl.is/xsd/IcelandicOnlineBank- ing Statements.wsdl for the banking statements, currency and N O T E more. With this in place you can use
the test user L621077B2B, We recomend that you add the following code on your project to passw. L6192965, to connect. begin with in order to be redirected onto our test enviroment :
statements.Destination = new EndpointReference (new Url ("https://b2bws.fbl.is/statements.asmx"), new Url ("https://b2bws.fbl.is/test/ statements.asmx"));
You will also need to aquire a certificate from Audkenni (www.audkenni.is) . In order to be able to connect to the B2Bws system a B2Bws user needs to be created even if the user already exists for the Corporate Internet Bank. B2B usernames have B2B as a postfix except for credit collection agencies which have B2BMI as postfix.
Timestamps It is necessary to make sure that the clocks are as synchronized as possible on clients and servers. The reason for this is that SOAP messages include a "Time to live", which is important because the system will not perform operations which do not arrive within a reasonable time. The services ! in this document use a default time of 900 seconds .
8
UserNameToken Each call to the service should include a UserNameToken in accordance with the OASIS WSS User- nameToken Profile 1.0. The token should include the Username and Password tags. The Pass- word@Type attribute references by default the URI „...#PasswordText“ and the password should be sent as clear text.
...
...
...
A sample of a security header The Nonce and Created tags are optional and their usage will not be enforced server side.
Signing messages Digital signature of messages is mandatory. Each banking institution defines its own rules for which types of certificates can be used for the services. This means that certificate which is used at one bank may, or may not, be accepted by other banks.
! Landsbanki accepts certificates, whether they are based on smartcards or not.
9
Security in B2Bws
In order to insure message integrity all messages are signed using a private key. This means that it is impossible 1 to modify the message without the receiver knowing it. Both the request (for the client) and response (for the server) message are signed. SSL is used to enforce message confi- dently, that is only the server and the client can read messages. WS-Security describes how to attach signature and encryption headers to a SOAP message. WS-Security also describes how to attach security tokens. In B2Bws we use the X.509 Token and the Username Token.
• The simple object access protocol (SOAP) o http://www.w3.org/TR/soap • Secure socket layer (SSL) o http://wp.netscape.com/eng/ssl3 • Web Services Security 1.0 o http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message- securiy-1.0.pdf
Certificate A valid certificate issued by Auðkenni is needed. Auðkenni issues two different types; personal certificate (persónuauðkenni) and ON THE WEB employment certificate (starfsauðkenni) . The main difference be- For more information on this tween the two is that the employment certificate is associated matter; go to Auðkenni’s web- with the employers ID number (kennitala). site www.audkenni.is.
1 There may in the future be some sort of a breakthrough mathematical that may make it possibale.
10
IcelandicOnlinePayments
Payment(DoPayment) A description of how single payments are created. The object Payment has a list of PaymentOut and PaymentIn, which are the withdrawals and deposits, along with the date the payment shall be made. If a payment date is not entered, it is generally assumed that the payment shall be per- formed the very same day.
A more detailed description of the sub-items of Payment follows on next page:
11
Out Here we describe the withdrawal that takes place during payment. The only thing that must be entered here is the account number and the ID of the account owner. Category code, reference number and bill number can be entered and that information will be accessible when account statements are viewed. A receipt (intended for the payer) can also be sent in the form of snail mail, e-mail and/or SMS.
12
In A choice is made between four types of deposits, AB-giro, C-giro, Payment bills and standard transfers . One of these must be selected. The amount in question must also be entered, but a ! receipt and a description of the payment are optional. The BookingId is thought as an supple- mentary field that the users can use to link payments into their own accounting systems.
13
ABGiro Mandatory fields are the account ID (to which money will be deposited), the reference number for the payment and the bill number of the giro to be paid. The category code field is optional.
CGiro Mandatory fields are the account ID (to which money will be deposited), the personal ID of the account owner and the bill number for the giro. The category code field is optional.
PaymentSlip All fields are mandatory, the account (to which funds will be deposited), the ID number of the payer and invoiced (depends on the ledger), the due date of the slip and the IsDeposit fields dictates whether this payment is a partial or complete payment of the slip.
14
Transfer A standard transfer to an account. Mandatory are the account N O T E number and the ID number of the account owner fields (of the ac- count that funds will be deposited to), and optional fields are for When a payment batch has been sent from the category code, reference number and the bill number. the accounting system, an unpaid batch is im- mediately created in the Corporate Internet Banking and awaits the user. The actual trans- fer of funds does not occur until the user has confirmed the batch for payment using a se- curity code.
NICE TO KNOW ...
Illustrations courtesy of Corporate Internet Bank For those who choose it, Corporate Internet Banking also offers a special payment confirm- ation process . This process requires that more than one user approve the payment instruct- ions (that is, the batch for payment) before the actual transfer of funds is made. The company itself determines the number of approving parties required.
It is possible to set up various approval pro- cesses, dependent on amounts, and to assign various authorisation levels to employees. Users can therefore have differing approval au- thorisations for differing payment amounts.
In order to activate the approval process, it is necessary to register the company and its us- ers with the Corporate Service Desk by calling +354 410 9191 or sending an e-mail to fyrir- [email protected] .
15
Receipt Receipts are sent to the payment recipient when it is performed. This is an optional field on both in and out payments. The choice stands between sending PostalMail (a standard letter mail), E- mail and SMS. The options are sending 1 PostalMail, 3 emails and 3 sms’s. If PostalMail is select- ed, then a recipient must either be entered by using the ReceiverAddress or by setting the Use- PersonID field as true, in which case a receipt is sent so the recipients home as listed in the national register. The ReceiverAddress consists of a name, two address lines, the postal code, city, region and country. If it is selected to send an email, then only the email address must be en- tered. If it is selected to send an SMS, then a country code and phone number must be entered.
16
PaymentsResult (DoPaymentResponse) This is a description of the response to a creation of a single payment (the results for a payment batch). ID is the unique identification for the batch that was NOTE created and Status is the batch status. Success and Errors are kept optional, be- If a future date for cause it is always possible that one of those would be completely empty. In Suc- payment was selected cess and Errors the payments just created are being returned. in the payment creat- ion, then that date is returned here in Date- OfPayment , and the status of the batch is put as OnHold .
Success A list of payments that were successfully performed. The amount of the payment is shown. AGiro, CGiro and Transfer are identical to the actual payment, but PaymentSlip changes in the way that more detailed information about the interests and fees for the payment is given.
17
PaymentSlip (in Success) The key in the PaymentSlip that is a part of the payment, is only a little part of the answer, as a part of PaymentSlipInfo. Added to it are details about the payment slip.
18
Errors A list of the payments that an error occurred on and could therefore not be created. The item Payment is identical to the one previously described in this document.
Error A more detailed description of the error that occurred. Code is the number of the error and Mes- sage a description of the error that occurred.
19
Payments (DoPayments) A description of how a list of payments is created. The element Payments has one field for a with- drawal and 1 to 500 possible deposits. Payments also has two attributes, RollbackOnError and IsOneToMany. RollbackOnError means that if any one of the payments fails, then all payments are cancelled. IsOneToMany indicates whether one withdrawal should be made for the entire batch or if one withdrawal should be made per deposit. A date for forward payment and a batch name can also be entered, but those elements are optional. In and Out elements are identical to the ones in creation of a single payment.
The response to a batch creation is OperationID which is a string variable that is an identifier for the operation.
20
Payment query (GetPaymentResult) An OperationID (string) is sent for the payment to be fetched.
PaymentsResult The response to the query. Same answer as to the creation of a single payment.
Payments query (GetPaymentsResult) A query is sent that consists of a paymentID (string), and a filter that contains PaymentStatus. Using the filter, it is possible to get the status of payments (GetStatus), get all payments on errors (GetErrors), get all successful payments (GetOkay) and get all payments (GetAll).
The answer to this query is the same as in GetPaymentResult, except that in this case it is more likely that the lists are used more than in the single payment.
21
IcelandicOnlineStatements
AccountStatement (GetAccountStatement) GetAccountStatement has one element AccountStatement, which is used to perform a query on an account. The mandatory fields for this query are the account number (Account) and the start and end dates of the statement. It is also possible to select specific records from within the statement. This is added for the user, in case there are many entries within the same period.
NICE TO KNOW ...
Landsbanki co-operates with several foreign If the company’s foreign bank is not already a banks to publish their account statements in co-operating partner Landsbanki will seek its the Corporate Internet Bank. Landsbanki’s co-operation in close relation with the comp- customers, who have foreign bank accounts, any. can use Landsbanki’s Corporate Internet Bank instead of other internet banks to get an To activate this service please register the overall summary of their bank accounts and company and its users at Companies’ Service thus save a considerable amount of time and Desk , tel. +354 41022 9191 or at fyrirtaeki@ effort. landsbanki.is.
Get AccountStatementResponse: An account statement, contains information about the account itself, as well as all the account entries (Transactions), but that element is not returned if no entries were found.
23
Transactions The element Transaction in the account statement contains a list of entries (AccountTransaction- Array). Each account transaction has a detailed description of the information regarding an account statement entry.
24
CurrencyRateRequest If a query is received regarding the current day’s exchange rate, the exchange rate posted most recently is sent. If a customs rate query is sent, then the current customs rate is delivered. An exemption is the monthly date on which the customs rate is changed, when the customs rate cannot be obtained before 12:00hrs. The customs rate is changed on the 28th of each month provided that this date is a banking day. Otherwise, it is changed on a the banking day immediat- ely following, unless that day is in the following month, in which case it is changed on the banking day immediately preceding the 28th day of the month. All currencies are displayed in each query.
When a query is made regarding currency rate, the date of the rate in question is entered, as well as a CurrencyType element which dictates which type of rate is to be fetched.
Currency rate (CurrencyRateResponse) The response returns a list of CurrencyRate elements. The rate elements are made optional be- cause if the query is made for customs rate, then only the customs rate is returned, and not the selling rate or buying rate. It’s the same thing when the query is made for note rate or exchange rate.
Usercase Illustrations courtesy of Annata Exchange rate handling is an example of a financially insignificant operation. For this reason, it is often carried out without a password, so that the accounting syst- em retrieves the exchange rate from the bank (for example, on a daily basis) in a so-called batch job. The employee is un- aware that the exchange rate has been retrieved but can verify it in the account- ing system’s operation summary.
However, the bank recommends that the query window (left-hand screen shot) al- ways be available, in case the company needs to retrieve the exchange rate with- out prior notice. 25
IcelandicOnlineClaims
Claim creation / Claim modification (CreateClaims / AlterClaims) NOTE Receives a list of claims, that consists of Claim elements. The handling of a single
claim is explained later on in this chapter.
26
ClaimKey A unique key for a claim, that consist of the personal ID of the claimant, account (bank, 66, claim- number) and its due date.
NoticeAndPaymentFee The fee for sending a notice to the payer, but printing out the claim is optional.
Usercase Illustrations courtesy of Annata Payment references play an important role in the handling of all accounts receivable. They are required in order for automatic re- conciliation to take place in the accounting system.
If a reference does not exist – for example, when a deposit is made directly to the claimant’s bank account (bypassing the pay- ables pool) – account statements are used for reconciliation and balancing in the accounting system.
27
CancelClaims Sends in a list of keys for the claims to be cancelled. The claim key is the same as in the creation / modification of claims.
The response to CancelClaims is the same as to creation/modification, i.e. CancelClaimsResponse that contains the string OperationID.
NOTE
This is the same ClaimKey as previously shown.
28
GetClaimOperationResult OperationID (string) is sent for the operation that information is to be col- NOTE lected about. The answer: GetClaimOperationResultResponse that contains ClaimOperationResult. This result concerns multiple claims, not individual ones.
29
Claims is a list of the claims that were successfully created, i.e. the claim key and information on whether it is to be printed or not.
The claim key is its unique identifier. All elements are mandatory.
NOTE This is the same ClaimKey as previously shown.
The list of errors in ClaimsResult is the same type as previously shown, e.g. in payments.
30
QueryClaims A query on claim status, which uses the ClaimsQuery type. The only mandatory element is Claimant, which is the claim owner. Other elements NOTE speak for themselves, except that it should be noted that specific entries If a query is sent concerning a within the result set can be selected, e.g. entries 1 through 10 of all entr- set of payables , the response ies found. will show deposits made until and including midnight on the last working banking day.
If a query is sent concerning an individual payable , the re- sponse will show its real-time status at that time (intraday).
Usercase
Software companies can link information from their cust- Illustrations courtesy of Annata omer systems to the response to the query. It is useful to add columns that show the direct phone number and e- mail address for each payor, or whatever information col- lections personnel can use from their own systems. This can be tailored to suit the customer’s needs and desires.
31
The answer to QueryClaims is QueryClaimsResponse, which contains QueryClaimsResult.
The claims in the list Claims are of the type ClaimInfo, but basically they are the same as the type Claim which has previously been described, with a few added elements. It includes more details about the costs that apply to the claim, e.g. default charge and discount. These additional ele- ments are depicted below.
32
DefaultCharge A charge that is added to claims once they end up in default. There are 2 different charges, first and second default charge. They both consist of an amount and a percentage.
DefaultInterest Dictates which default interest rule to use if a claim becomes default.
NICE TO KNOW ...
Illustrations courtesy of Corporate Internet Bank
The Corporate Internet Banking’s billing system offers payment deadlines that B2B users can use on the Internet, but not with XML messages.
If an extension of time to pay is authorised, FBL carries out automatic tracking to ensure that the payor remits payment by the agreed deadline, Users with the classic LÍ scheme can utilise XML payment dead- and the system takes action automatically if he does not do so. Response lines. This is described in Landsbanki’s B2B manual. to non-payment could include the following (in part or in whole): • Calculation of default charges • Dunning letter • Warning • Secondary collection 33 • Legal collection
Currency information An optional element on a claim, but is used for currency claims.
34
Discount Which discounts are given on a claim, and look very similar to the default charge.
NOTE
Discounts are based on five areas: • First discount • Second discount • Number of days for first discount • Number of days for second dis- count • Discount code
The discount code states what date shall be used as a reference when a discount is granted. Further discus- sion of discounts can be found in the IKLÍ Handbook , which can be obtained by sending an e-mail to the Corporate Service desk : fyrir- [email protected] .
35
Bill Presentment System Which presentment system to use, determined by the Type element, and a NOTE reference to specific system using parameters. Fur ther information on the Bill Presentment System is cordially granted at our Corporate Serv- ice Desk in +354 410 9191 or [email protected] .
36
Printing A description of how a claim is to be printed if done so by a banking institution. All elements in the printing section are optional.
37
CreateClaim/AlterClaim The creation and the modification of a single claim is the same as in Claims , except that here it is always a single claim that is being processed, not a list. The claim itself looks the same, but the ! answer to creation / modification is a ClaimOperationResult.
38
ClaimOperationResult Information about the result of an operation. A list of claims and/or errors is NOTE returned. Information about printing and direct payment only applies when a claim is created. This result concerns an indi- vidual claim.
39
CancelClaim The cancellation of a claim is the same as in Claims, i.e. the key for the claim to be cancelled is sent, but here it is al- ways a single claim that is being proces- sed.
The answer to the cancellation is the same as in the create/alter operation, i.e. ClaimOperationResult.
40
ClaimQuery A query on a single claim. Uses the claim key. NOTE
If a query is sent concerning a set of payables , the response will show deposits made until and including midnight on the last working banking day.
If a query is sent concerning an individual payable , the re- sponse will show its real-time status at that time (intraday).
41
The answer to QueryClaim is QueryClaimResponse, which contains QueryClaimResult which is the type ClaimInfo, but that is the same type as returned in ClaimsQueryResult.
42
QueryPayments Uses the element query which is of type PaymentsQuery. It is possible to NOTE search for specific entries within the result set, as previously done with Claims. Here you are only fetching pay- ments from payables pool . The company uses Icelandic Online
Statements to view all deposits, including transfers .
The answer to the QueryPayments query is QueryPaymentsResponse which has the element QueryPaymentsResult which is type QueryPaymentsResult. That contains a list of payments, as well as the total number of payments returned.
43
The list Payments contains a list of Payment.
44
The key in Payment is the same as previously shown, i.e. the claim key.
NOTE
This is the same ClaimKey as previously shown.
In addition, currency information is available for currency claims, but that type (CurrencyEx- changeRate) only contains information about the currency and its rate.
45
IcelandicOnlineSecondary CollectionClaims
It generally applies to secondary collection companies that the they have all the same options on claims as normal companies, with the exception of claim creation. In addition, several specific operations are added for secondary collection companies as well as minor modifications of the queries.
SecondaryCollectionPaymentsQuery The way for secondary collection companies to query about payments. Fetches the payments that have been processed, where it is possible to retrieve claims sorted by claimants. If that is not done, then all claims within the given time period are fetched.
46
QueryClaims This function is used to fetch all claims that are now available for secondary collection but have not yet been taken into collection by the collection company. In Order to take claims into secondary collection the collection company must use the “alterClaim/alterClaims” method to gain control over the claim.
AlterClaim(s) The way for secondary collection companies to take ownership of the claims as well as adding additional cost, it uses the same layout as Create-/Alter-Claims on page 35.
SecondaryCollectionClaimsQuery The way for secondary collection companies to query about claims that they now have control over. All elements in the query are optional, but if none of those are used, than it is assumed that all claims that have come into collection for this company are to be fetched. As it is with the payment query, it is possible to narrow the search down to individual claimants.
Claim return (SecondaryCollectionReturnClaim) Secondary collection companies have the opportunity to return claims that have reached the secondary collection status. It uses a list of claim keys for NOTE the claims that are to be returned. The secondary collection firm returns, through its actions, a set of claims and not an individual claim to the creditor.
47
Error messages
General All communication is prone to exceptions and SOAP has a standard mechanism to communicate exceptions. These SOAP Exceptions are only thrown when it is not possible to complete an oper- ation, usually due to faulty data or other technical reasons. Additionally, some circumstances where the input data does not conform to a given criteria can lead to an exception being thrown. When executing a batch, where it is possible for some operations to succeed but not others, oth- er ways of returning error information is preferred.
Exceptions Special error messages are returned in the details node of a SOAP exception when the error does not deal with SOAP headers. The different nodes returned in the details node are described in the following table:
Code Type Details
GeneralErrorCode xs:string Common error code across banking institutions.
GeneralErrorText xs:string Text to describe the GeneralErrorCode. ex: "Authentication failed", "Data could not be validated" etc.
BanksErrorCode xs:string Error code specific to the banking institution and the error in- stance. BanksErrorText xs:string Text to describe the BanksErrorCode and/or data to resolve or help troubleshoot problems between banking institutions.
The BanksErrorCode can be used by each individual institution to identify individual error occur- rences, e.g. to enable tracking. The GeneralErrorCodes are common error codes and indicate which class of error has occurred.
Code Text Details 0001 Service is Unavailable. Implies that the service is closed for some reason. 1000 An error occurred. A general error if a more detailed description is not available. 1100 Access to the operation is not pre- sent. 1200 Data could not be validated. The data could not be validated according to the XML schema. 1300 Business logic error. Business rules were broken, e.g. dates or amounts were not valid.
48
Schemas https://b2bws.fbl.is/xsd/envelope.xsd https://b2bws.fbl.is/xsd/envelope.xsx N O T E https://b2bws.fbl.is/xsd/IcelandicOnlineBanking.wsdl The schema index can be https://b2bws.fbl.is/xsd/IcelandicOnlineBankingClaims.wsdl found at the following url: https://b2bws.fbl.is/xsd/IcelandicOnlineBankingClaimTypes.xsd https://b2bws.fbl.is/xsd https://b2bws.fbl.is/xsd/IcelandicOnlineBankingClaimTypes.xsx https://b2bws.fbl.is/xsd/IcelandicOnlineBankingPayments.wsdl https://b2bws.fbl.is/xsd/IcelandicOnlineBankingPaymentTypes.xsd https://b2bws.fbl.is/xsd/IcelandicOnlineBankingPaymentTypes.xsx https://b2bws.fbl.is/xsd/IcelandicOnlineBankingSecondaryCollectionClaims.wsdl https://b2bws.fbl.is/xsd/IcelandicOnlineBankingStatements.wsdl https://b2bws.fbl.is/xsd/IcelandicOnlineBankingStatementTypes.xsd https://b2bws.fbl.is/xsd/IcelandicOnlineBankingStatementTypes.xsx https://b2bws.fbl.is/xsd/IcelandicOnlineBankingTypes.xsd
49
50
Memos
______
______
______
______
______
______
______
______
______
______
______
______
______
______
______
______
______
51
______
______
______
______
______
______
______
______
______
______
______
______
______
______
______
______
______
______k
52
November 2007 Landsbankinn | [email protected]
53