Design of transfer system between securities and banks

Design

In order to facilitate the transfer of funds between his stock fund account and bank account, an application layer protocol is needed to realize this function. Generally is based on the TCP/IP Protocol design High-level application protocol, and through a specific application to achieve this function. Now the implementation is based on the client/server model to achieve this function, the securities company as a client, and the bank as the server side. In this way, the securities company to a large extent can only choose a bank to achieve the allocation of accounts, so that users in other banks to account for the relatively inconvenient.
We designed a protocol architecture that transfers through communication between WWW servers to ensure that a securities company can interact with multiple banks at the same time, and that a bank can interact with multiple securities companies simultaneously.
The design of our protocol is based on the XML markup model (element/attribute). One of our purposes is to establish a communication protocol that is unrelated to implementation. Each message consists of a valid XML document that interacts with each other at both ends of the communication (Banks and securities) by sending and receiving documents.
In fact our protocol is based on HTTP and is transmitted via HTTP. We are using the Post/response mechanism of HTTP. Our agreement does not in itself take into account security issues, as the organization is developing some very reliable security mechanisms through which our communications security can be achieved. Encryption can also be implemented at the transport layer, such as through SSL,PGP or S/MIME. Both sides of the communication can authenticate by using a certificate in the communication layer.

General description of Protocol design
The premise that the user's funds can be transferred between the securities company and the bank is that the user must have his or her own account in the bank and securities company, for example, if the securities company user needs to have a stock fund account and a current account in the bank (only the demand deposit can be allocated at any time) The agreement we designed does not take account of these account accounts, that is, we believe that these accounts have been established.
The agreement we designed allows users to transfer functions both in the bank and in the Securities company. As long as the two organizations are connected and users have their own accounts in both organizations. In fact, for example, at the bank, the bank will keep all the information related to the user's current account, if the user needs to handle the transfer function at the bank, as long as the user can provide the bank current account number and the correct password, but also can provide the securities company's capital account number and password, The system will first find out if the current account number exists locally, the password is consistent, if it is, it will determine whether the current account has been with the user provided by the Securities Company's Fund account, if it has been linked, then return an error message that the user has handled the business. If not, the Bank communication server will be linked to the relevant communications Server of the securities company, if the securities company returns the information that the user provided the funds account number and password are correct, so that in the bank and the securities companies in the relevant database, respectively, add a logo, To indicate that a particular fund account has been associated with a particular demand account. In this way, the transfer function is established. At the same time, an authorization code is randomly generated, which is the password that the user needs to type when making the transfer, which indicates that the user has permission to perform the operation. In fact, the basic process of handling the transfer function on the securities company side is similar to this one.
After the user has transacted the transfer function, in fact, the user can own the fund account transfer through the browser (need to support XML format). At the time of allocation, it should be noted that transfers can be made only when the balance in the account is greater than the amount to be allocated. When this condition is met, the user can either transfer some of the money in the demand account to the fund accounts or transfer the money from the funds account to the demand deposit. It greatly facilitates the scheduling and operation of the user funds.
The agreement we designed is mainly for the communication between the money transfer server of the securities Company and the bank's transfer server, and the transfer server of a securities company can communicate with the transfer server of a plurality of banks, and the transfer server of a bank can also communicate with the transfer server of several securities companies. In fact, these communication servers can be considered to be WWW servers.

Protocol Design Detail Description
Below we describe in detail the design of the protocol and the details of the relevant implementation:
Protocol Package Overall format
First we look at the overall architecture of the entire communication protocol:
! ELEMENT Information Payload (information header, (Request Information | response information))
! ATTLIST Information Load
Version number CDATA #REQUIRED
Time Label CDATA #REQUIRED
>
A message consists of three elements: an information payload, an information header and request information, or a response message. The information payload is a description of the packet attribute, which is used to represent the sender and receiver of the message, and the request information or the response information is the main content of the message.

The information payload includes two properties:
Version number: Used to indicate the version used by the communication, you must ensure that both sides of the communication use the same version number. Here we set to 1.0
Time label: Used to indicate when the packet was issued. The format of the actual time tag is set to: YYYY:MM:DDTHH:MI:SS, where T is a delimited identifier for the date and time. For example: 2000:03:01t10:22:33 is a valid time tag.

The following is a definition of the header:
! ELEMENT Information Header (message sender, information receiver)
The information header is composed of two parts, the sender of the information and the receiver of the information. Used to represent the sender of a message and the receiver of the message. The message sender and receiver have the same properties. They are defined in the following format:
! ELEMENT Information Sender empty>
! Attlist Information Sender
Name CDATA #REQUIRED
Sender ID CDATA #REQUIRED
Role (Bank | securities) #REQUIRED
>
! ELEMENT Information Recipient empty>
! ATTLIST Information Receiver
Name CDATA #REQUIRED
Recipient ID CDATA #REQUIRED
Role (Bank | securities) #REQUIRED
>
They all have three attributes: where the name refers to the sender of the message or the name of the receiver, such as: ICBC Shanghai Branch is a valid sender or receiver name. The recipient ID is used to uniquely identify a sender or receiver, and there are two mechanisms at the time of implementation. One is simply using a URL as the unique identifier for the sender or receiver. In addition, a UUID can be set up for each sender or receiver to ensure a unique identification of a sender or receiver. A role is the identity of the sender or receiver of a message, whether it is a bank or a securities company.

Request Information Protocol format
Here we introduce the main part of the information, first we introduce the request information, the following is the definition of the request information:
! ELEMENT Request information% transaction form
! Attlist Request Information
Request Information ID CDATA #REQUIRED
>
! ENTITY% Transaction Form "Transfer account +| Transfer | Transaction Inquiry +| Transaction Management |>"
The main features of the request information are transfer accounts, transfer, transaction inquiries and transaction management, which are related to the transfer business. The request information includes only one attribute, the ID number of the request information, and the request information ID number must be unique in all packets from Server A to Server B, that is, each packet must have a unique ID number. In a packet can be submitted at the same time several transfer account application, which gives the implementation of a certain degree of flexibility. The server can quickly process each user's application, or can be processed in batches according to the specific situation. The server can also submit multiple transaction queries at the same time.

Transfer account opening transaction format
We first look at the transfer account transaction:
! ELEMENT Transfer Account Data set
! Attlist Transfer Account
Account opening Message ID CDATA #REQUIRED
Transaction Code CDATA #REQUIRED
Transaction proposed (Shareholder | depositor | Bank SYSTEM | Securities system) #REQUIRED
>
Bank account three attributes are available: The Account ID guarantee that in all of the once submitted application business, each has a unique ID number. That is, you must ensure that the ID is unique within a package scope. The trading code is designed to make it easier for the machine to handle the business. The transaction indicates who triggered the business, whether it is a shareholder, a depositor, a server system at the bank, or a server system on the security side.
The money transfer business contains a data set, and the contents of the data set are described below in detail. Here, briefly, the data group is mainly used to represent the transaction between the server and transactions related to the delivery of business data, such as funds account number, transaction amount and other data.

Transfer Transaction format
Next we'll look at the transfer transaction:
! ELEMENT Transfer (capital account transfer out of current account to +|
Current account transfer out of funds account to +|
Transaction Results query +) >
! ELEMENT Capital account transfer out of current account to data set
! Transfer of ATTLIST funds account to a current account
Fund account transfer out of current account into message ID CDATA #REQUIRED
Transaction Code CDATA #REQUIRED
The transaction is presented (shareholder | depositor) #REQUIRED
>

! ELEMENT current account transferred out of fund account to data set
! Attlist Current account transfer out of funds account transfer
Current account transfer out of funds account to message ID CDATA #REQUIRED
Transaction Code CDATA #REQUIRED
The transaction is presented (shareholder | depositor) #REQUIRED
>

! ELEMENT Transaction Results query (related message status +)
! ATTLIST Transaction Results Query
Transaction result query Message ID CDATA #REQUIRED
Transaction Code CDATA #REQUIRED
Transaction proposed (Banking system | Securities system) #REQUIRED
>
! ELEMENT related message state Data Group >
! ATTLIST Related message Status
ID of the request message CDATA #REQUIRED
The ID of the message to query CDATA #REQUIRED
>

The transfer transaction is the core of the business, and it is actually dealing with the transfer of funds between the bank and the securities, mainly in two modes, the transfer of the Fund account to the current account and the transfer of the current account to the Fund account.

Let's analyze the transfer of the funds account to the current account. When the shareholders or depositors make the transfer request, consider general, we set up a transfer request, the securities company end of the server will analyze the amount of money required to transfer is less than the balance of funds account, if established, reduce the balance of the fund account, The packet is then sent to the bank's server, and if the bank's server handles the message correctly, it increases the balance of the relevant current account and returns the result of the operation to the security party's server.

However, it is possible that the security server will not receive the answer message (possibly because of the packet loss) after issuing the transaction order. It is for this reason that a query for the results of a transaction is required. A transaction result query can also query for multiple messages that have been sent but not answered in time. The attribute in the related message state element: The ID of the message to query is the ID number of the message that is not responding. ID of the request message this property represents the ID number of the request package associated with the request. The combination of the two attributes only determines a single message. For example, the security server issued three funds account transfer out of the current account into the message, but for a long time did not respond, you can issue a transaction results query this instruction to the bank server to check the implementation of the three messages.

Transaction query format
After analyzing the transfer transaction, we will analyze the implementation of the transaction query. The agreement format for the transaction query is defined as follows:
! ELEMENT Transaction Inquiry (Day transaction Detail Inquiry +|
Historical Transaction Detail Inquiry +|
Current account balance Inquiry +|
Fund account balance Enquiry +)
>
! ELEMENT Day Transaction Detail query Data group >
! Attlist Day Transaction Detail Inquiry
Day Transaction detail Query ID CDATA #REQUIRED
Transaction Code CDATA #REQUIRED
The transaction presents the shareholder | The depositor) #REQUIRED
>
! ELEMENT History Transaction Detail Query Data group >
! Attlist Historical Transaction Detail Inquiry
Historical Transaction Detail Query ID CDATA #REQUIRED
Transaction Code CDATA #REQUIRED
The transaction presents the shareholder | The depositor) #REQUIRED
>
! ELEMENT Current account balance query data set
! Attlist Current Account Balance Enquiry
Current account balance Query ID CDATA #REQUIRED
Transaction Code CDATA #REQUIRED
Transaction proposed CDATA #FIXED "shareholder"
>
! ELEMENT Fund account balance Query Data group
! Attlist Fund Account Balance Inquiry
Fund account balance Query ID CDATA #REQUIRED
Transaction Code CDATA #REQUIRED
Transaction proposed CDATA #FIXED "savers"
>

Transaction inquiries are mainly initiated by shareholders or depositors. There are four main forms: inquires the day transaction detail, the historical transaction detailed inquiry, the current account balance inquiry and the fund account balance inquiry. If the user is in the securities that end of the query, if the inquiry day transaction details, the security server will communicate with the bank server, the bank server returned to the day of the transaction details of all the successful transaction details. If the user is at the end of the bank, just the opposite. The purpose of this is to ensure that the user is seen to be a successful transaction. At the same time, if the user checks the fund account balance on the security side and inquires the current deposit balance on the bank side and this agreement does not have the relation, because all can be found directly on the local server. It is worth noting that in a packet (actually an XML document) a request can be sent from multiple users at the same time.
Transaction Management format
The agreement format for transaction management is as follows:
! ELEMENT Transaction Management (Bank Reconciliation/Securities Day Final Reconciliation |
Closed Transfer Trading Function | Open Transfer trading Function |
Modify Authorization Code)
>
! ELEMENT Bank day End Reconciliation Data Group
! Attlist Bank Reconciliation in the end of the day
Bank day-end reconciliation ID CDATA #REQUIRED
Transaction Code CDATA #REQUIRED
Transaction proposed CDATA #FIXED "banking system"
Detail file CDATA #REQUIRED
>
! ELEMENT Securities day End Reconciliation data set
! ATTLIST Securities Day End Reconciliation
Securities Day to end reconciliation ID CDATA #REQUIRED
Transaction Code CDATA #REQUIRED
Transaction proposed CDATA #FIXED "Securities System"
Detail file CDATA #REQUIRED
>
! ELEMENT closed Transfer Transaction functional data set
! ATTLIST Closed Transfer Transaction function
Closed Transfer Transaction function ID CDATA #REQUIRED
Transaction Code CDATA #REQUIRED
Transaction proposed (Shareholder | depositor | Bank SYSTEM | Securities system) #REQUIRED
>
! ELEMENT Open Transfer Trading functional data set
! ATTLIST Open Transfer Transaction function
Open Transfer Transaction function ID CDATA #REQUIRED
Transaction Code CDATA #REQUIRED
Transaction proposed (Shareholder | depositor | Bank SYSTEM | Securities system) #REQUIRED
>
! ELEMENT Modify Authorization Code data set
! ATTLIST Modify Authorization Code
Modify Authorization Code ID CDATA #REQUIRED
Transaction Code CDATA #REQUIRED
The transaction is presented (shareholder | depositor) #REQUIRED
>

Because some transactions are not confirmed during package transfer, the Bank and the securities parties must reconcile each other after the end of the day's business. This is done through the bank Reconciliation and Securities Day final reconciliation two news. Include an attribute in the daily reconciliation element as a detail file, which is actually the name of the file that contains the details of all the transactions that were turned out and transferred on the same day. In concrete implementation, the system can be based on this property through FTP to get the file, so that banks and securities parties to obtain a detailed transaction details of each other to reconcile. Users, banks and securities can request the temporary closure of the transfer transaction function in accordance with their special circumstances, or the open Transfer transaction function. The user can request a change of authorization code during the system's working hours.
Response Information Protocol format
Both the Securities party and the bank can make a request to the other's server, and the server receiving the request returns a response message to the requesting server after processing the request. The
Protocol format definition for the response of the request:
ELEMENT Response Information (response reply +) >
! Attlist Response Information
Response information ID CDATA #REQUIRED
>
! ELEMENT Response Answer Data group *>
! Attlist Response
Answer code CDATA #REQUIRED
Answer Code description CDATA #REQUIRED
Request Message ID CDATA #IMPLIED
Related Message ID CDATA #IMPLIED
>
Each response message packet has a response message ID used to uniquely identify the response packet. A response message can contain multiple response responses. Because multiple requests may be included in a request package, such as in a data packet that requires a bank account to be opened, a few users may be required to make the transfer function. So you need to respond to these several request messages at the same time. The answer code in the response element, we take the three-digit digit character. For example, 200 indicates that the message was successfully processed. 301 means the current account does not exist and so on. The ID of the request message is the unique identification number of the request packet, and the ID of the associated message refers to a specific request in the packet, such as a query that requests a transfer of a fund account to a current account. Where the data group refers to a collection of data items that are related to the request that need to be returned.
Data Group Description
defines the format for data sets and data items:
!--Data Group description-->
! ELEMENT Data Group (data item) + >

!--Data Item Description-->
! ELEMENT Data Item empty>
! Attlist Data Items
Data element name CDATA #REQUIRED
Type CDATA #REQUIRED
Length CDATA #REQUIRED
Whether the fixed length (is | no) #REQUIRED
Data meta content CDATA #REQUIRED
>
A data group consists of data items that, depending on the transaction's specific, have different transaction requests that contain different sets of data, and the responses to different transactions include different data sets. Each data item defines the name, type, length, fixed length, and actual content of the data item.
A practical example of interaction
Here we look at an example of an actual interactive process in which a shareholder opens an account:
The requested packet is:
<?xml version= "1.0"? > >
! DOCTYPE Funds Transfer
SYSTEM "http://www.somestandard.org/Bank Securities Information Exchange Agreement-DTD "
>
Information load
Version number = "1.0"
Time label = "2000-01-01t02:02:23"
>
Information Head
Message sender
Name = "Stock Corporation"
Sender id= "4af37b30-2c35-11d2-be4a-204c4f4f5020"
Role = "Securities"
/>
Information receiver
Name = "Bank Corporation"
Recipient Id= "3af37b50-2635-1172-b24a-26604f478021"
Role = "Bank"
/>
</Information Head >
Request Information
Request Information id= "3434234334" >
Investor Account
Account Opening message id= "2342342334"
Trading Code = "1540"
Transaction proposed = "Securities system"
>
Data Group >
Data item
Data element name = "Fund Account Number"
Type = "Numeric Character"
Length = "19"
Whether fixed length = "No"
Data element content = "000000000018"
</>
Data item
Data element name = "Fund account password"
Type = "binary character"
Length = "8"
Whether fixed length = "Yes"
Data element content = "********"
</>
Data item
Data element name = "Securities Company Code"
Type = "Numeric Character"
Length = "6"
Whether fixed length = "Yes"
Data element content = "123111"
</>
Data item
Data element name = "Current Account code"
Type = "binary character"
Length = "25"
Whether fixed length = "No"
Data element content = "2300232045018"
</>
Data item
Data element name = "Current account password"
Type = "Numeric Character"
Length = "8"
Whether fixed length = "Yes"
Data element content = "********"
</>
Data item
Data element name = "Bank Code"
Type = "Numeric Character"
Length = "6"
Whether fixed length = "Yes"
Data element content = "444222"
</>
Data item
Data element name = "Transaction Period time"
Type = "Numeric symbol character"
Length = "19"
Whether fixed length = "No"
Data element content = "2000-01-01t02:02:23"
</>
</Data Group >
</Shareholder Account
</Request Information > >
</Information Load >
In fact, the document is sent from the security server to the bank server, and if the bank server successfully processes the request, the document returned should be in the following form:
<?xml version= "1.0"? > >
! DOCTYPE Funds Transfer
SYSTEM "http://www.somestandard.org/Bank Securities Information Exchange Agreement-DTD "
>
Information load
Version number = "1.0"
Time label = "2000-01-01t02:03:45"
>
Information Head
Message sender
Name = "Bank Corporation"
Sender id= "3af37b50-2635-1172-b24a-26604f478021"
Role = "Bank"
/>
Information receiver
Name = "Stock Corporation"
Recipient Id= "4af37b30-2c35-11d2-be4a-204c4f4f5020"
Role = "Securities"
/>
</Information Head >
Response information
Response Information id= "4587874878"
>
Response Answer
Answer code = "200"
Answer Code Description = "Successful Transaction"
Id= "3434234334" for the request message
Id= "2342342334" for related messages
>
Data Group >
Data item
Data element name = "Authorization Code"
Type = "Numeric Character"
Length = "10"
Whether fixed length = "Yes"
Data element content = "0012300454"
</>
Data item
Data element name = "Transaction Period time"
Type = "Numeric symbol character"
Length = "19"
Whether fixed length = "No"
Data element content = "2000-01-01t02:03:45"
</>
</Data Group >
</Response Answer
</Response Information >
</Information Load >

The contents of the primary data item
Data Item >
Data element name > Fund account number
Type > Digital character </type >
Length >19</length
Whether fixed length or not fixed length
</Data Item >
Data Item >
Data element name > Current account name
Type > Digital character </type >
Length >25</length
Whether fixed length or not fixed length
</Data Item >
Data Item >
Data element name > Authorization Code "data element name"
Type > Digital character </type >
Length >10</length
Whether the fixed length is the fixed length
</Data Item >
Data Item >
Data element name > Transaction amount "Data element name"
Type > Digital character </type >
Length >12</length
Whether the fixed length is the fixed length
</Data Item >
Data Item >
Data element name > Bank serial number "data element name"
Type > Digital character </type >
Length >12</length
Whether the fixed length is the fixed length
</Data Item >
Data Item >
Data element name > Serial number of securities company
Type > Digital character </type >
Length >12</length
Whether the fixed length is the fixed length
</Data Item >
Data Item >
Data element name > Bank code-Data element name >
Type > Digital character </type >
Length >6</length
Whether the fixed length is the fixed length
</Data Item >
Data Item >
Data element name > Bank name "Data element name"
Type > alphanumeric character </type >
Length >50</length
Whether fixed length or not fixed length
</Data Item >
Data Item >
Data element name > Securities company code data element name >
Type > Digital character </type >
Length >6</length
Whether the fixed length is the fixed length
</Data Item >
Data Item >
Data element name > Securities company Name "Data element name"
Type > alphanumeric character </type >
Length >50</length
Whether fixed length or not fixed length
</Data Item >
Data Item >
Data element name > Capital account number password "Data element name"
Type > binary character </type >
Length >8</length
Whether the fixed length is the fixed length
</Data Item >
Data Item >
Data element name > Current account password "data element name"
Type > binary character </type >
Length >8</length
Whether the fixed length is the fixed length
</Data Item >
Data Item >
Data element name > Current account balance "data element name"
Type > Digital character </type >
Length >12</length
Whether the fixed length is the fixed length
</Data Item >
Data Item >
Data element name > Fund account balance "data element name"
Type > Digital character </type >
Length >12</length
Whether the fixed length is the fixed length
</Data Item >
Data Item >
Data element name > Transaction period Time Data element name >
Type > Digital symbol character </type >
Length >19</length
Whether the fixed length is the fixed length
</Data Item >
Data Item >
Data element name > user name "Data element name"
Type > alphanumeric character </type >
Length >12</length
Whether the fixed length is the fixed length
</Data Item >
Data Item >
Data element name > User ID card data element name >
Type > digital </type >
Length >18</length
Whether fixed length or not fixed length
</Data Item >
Data Item >
Data element name > user address "data element name"
Type > alphanumeric character </type >
Length >80</length
Whether fixed length or not fixed length
</Data Item >
Data Item >
Data element name > Subscriber's Telephone "data element name"
Type > Digital symbol character </type >
Length >14</length
Whether fixed length or not fixed length
</Data Item >
Data Item >
Data element name > City number-Data element name >
Type > Digital character </type >
Length >5</length
Whether fixed length or not fixed length
</Data Item >