-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path239K.html
5407 lines (4750 loc) · 233 KB
/
239K.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<html>
<head>
<!--<meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"> -->
<title>Large HTML page with images</title>
<!-- The following link block and style block present methods how to load external CSS documents.
The link tag forces an immediate download of the CSS document whereas the import clause in
the style block has the document downloaded some random time later. -->
<link href="htmlparser/sections.css" rel="stylesheet" type="text/css">
<!--
<style type="text/css">
@import url(htmlparser/sections.css);
</style>
-->
</head>
<body>
<div align="center"><center>
<h1 class="fore">When to load CSS</h1>
<table border="0" cellspacing="5" width="100%" bgcolor="#F2F2FF">
<tr>
<td><p align="left"><font color="#000080" size="5" face="Tahoma"><strong>Large HTML page
with Images</strong></font></td>
</tr>
</table>
</center></div>
<hr>
<p><strong><small><font face="Verdana">This page shall test if the recorder generates
scripts with requests in correct order. It includes images in sequential order: stadyn_image1.gif
through stadyn_image10.gif</font></small></strong></p>
<hr>
<p><img src="stadyn_image1.gif" width="70" height="70" alt="stadyn_image1.gif (6512 bytes)"><br>
stadyn_image1</p>
<p><img src="stadyn_image2.gif" width="70" height="70" alt="stadyn_image2.gif (5983 bytes)"><br>
stadyn_image2</p>
<p align="center"><b><font SIZE="6">Open Financial Exchange<br>
Specification 1.0</font></b> </p>
<p align="center"><b><font SIZE="2">February 14, 1997<br>
</font></b></p>
<p align="center"><b><font SIZE="2">© 1997 CheckFree Corp., Intuit Inc., Microsoft Corp.
All rights reserved<br>
<br>
<br>
</font></b></p>
<p align="center"><i><b><font SIZE="5">Chapters 1 - 10<br>
<br>
<br>
<br>
<br>
</font></b></i></p>
<h1><img src="stadyn_image3.gif" width="70" height="70" alt="stadyn_image3.gif (6537 bytes)"><br>
<font SIZE="5">stadyn_image3</font></h1>
<h1><img src="stadyn_image4.gif" width="70" height="70" alt="stadyn_image4.gif (6028 bytes)"><br>
stadyn_image4</h1>
<p><img src="stadyn_image5.gif" width="70" height="70" alt="stadyn_image5.gif (4068 bytes)"><br>
stadyn_image5</p>
<p> </p>
<p> </p>
<h1><a NAME="_Toc371408167"><font SIZE="5">Contents</font></a></h1>
<p>1. Overview 51.1 Introduction 51.1.1 Design Principles 51.2 Open Financial Exchange at
a Glance 71.2.1 Data Transport 71.2.2 Request and Response Model 81.3 Conventions 92.
Structure 102.1 HTTP Headers 102.2 Open Financial Exchange Headers 112.2.1 The Meaning of
Version Numbers 122.3 SGML Details 122.3.1 Compliance 122.3.2 Special Characters 122.4
Open Financial Exchange SGML Structure 132.4.1 Overview 132.4.2 Top Level 132.4.3 Messages
132.4.4 Message Sets and Version Control 142.4.5 Transactions 152.5 The Signon Message Set
162.5.1 Signon <SONRQ> <SONRS> 162.5.2 PIN Change <PINCHRQ>
<PINCHRS> 192.5.3 Examples 202.6 External Data Support 202.7 Extensions to Open
Financial Exchange 213. Common Aggregates, Elements, and Data Types 223.1 Common
Aggregates 223.1.1 Identifying Financial Institutions and Accounts 223.1.2 Balance Records
<BAL> 223.1.3 Error Reporting <STATUS> 233.2 Common Elements 243.2.1 Financial
Institution Transaction ID <FITID> 243.2.2 Server-Assigned ID <SRVRTID>
243.2.3 Client-Assigned Transaction UID <TRNUID> 253.2.4 Token <TOKEN> 253.2.5
Transaction Amount <TRNAMT> 253.2.6 Memo <MEMO> 253.2.7 Date Start and Date
End <DTSTART> <DTEND> 263.3 Common data types 263.3.1 Dates and Times 263.3.2
Amounts, Prices, and Quantities 283.3.3 Language 283.3.4 Basic data types 284. Security
294.1 Security Solutions 294.1.1 Determining Security Levels <OFXSEC>
<TRANSPSEC> 294.2 Channel-Level Security 304.2.1 Security Requirements 304.2.2 Using
SSL 3.0 in Open Financial Exchange 304.3 Application-Level Security 314.3.1 Requirements
for Application-Layer Security 314.3.2 Using Application-level Encryption in Open
Financial Exchange 325. International Support 335.1 Language and Encoding 335.2 Currency
<CURDEF> <CURRENCY> <ORIGCURRENCY> 335.3 Country-Specific Tag Values
346. Data Synchronization 356.1 Overview 356.2 Background 356.3 Data Synchronization
Approach 366.4 Data Synchronization Specifics 376.5 Conflict Detection and Resolution
396.6 Synchronization vs. Refresh 406.7 Typical Server Architecture for Synchronization
416.8 Typical Client Processing of Synchronization Results 436.9 Simultaneous Connections
446.10 Synchronization Alternatives 446.10.1 Lite Synchronization 446.10.2 Relating
Synchronization and Error Recovery 456.11 Examples 467. FI Profile 487.1 Overview 487.1.1
Message Sets 487.1.2 Version Control 497.1.3 Batching and Routing 497.2 Profile Request
507.3 Profile Response 517.3.1 Message Set 527.3.2 Signon Realms 537.3.3 Status Codes
537.4 Profile Message Set Profile Information 548. Activation & Account Information
558.1 Overview 558.2 Approaches to User Sign-Up with Open Financial Exchange 558.3 Users
and Accounts 568.4 Enrollment and Password Acquisition <ENROLLRQ> <ENROLLRS>
568.4.1 User IDs 578.4.2 Enrollment Request 578.4.3 Enrollment Response 598.4.4 Enrollment
Status Codes 598.4.5 Examples 608.5 Account Information 608.5.1 Request <ACCTINFORQ>
618.5.2 Response <ACCTINFORS> 618.5.3 Account Information Aggregate <ACCTINFO>
628.5.4 Status Codes 628.5.5 Examples 638.6 Service Activation 638.6.1 Activation Request
and Response 648.6.2 Service Activation Synchronization 668.6.3 Examples 668.7 Name and
Address Changes <CHGUSERINFORQ> <CHGUSERINFORS> 678.7.1 <CHGUSERINFORQ>
678.7.2 <CHGUSERINFORS> 688.7.3 Status Codes 688.8 Signup Message Set Profile
Information 699. Customer to FI Communication 709.1 The E-Mail Message Set 709.2 E-Mail
Messages 709.2.1 Regular vs. Specialized E-Mail 719.2.2 Basic <MAIL> Aggregate
719.2.3 E-Mail <MAILRQ> <MAILRS> 719.2.4 E-Mail Synchronization
<MAILSYNCRQ> <MAILSYNCRS> 729.2.5 Example 739.3 Get HTML Page 749.3.1 MIME Get
Request and Response <GETMIMERQ> <GETMIMERS> 749.3.2 Example 759.4 E-Mail
Message Set Profile Information 7610. Recurring Transactions 7710.1 Creating a Recurring
Model 7710.2 Recurring Instructions <RECURRINST> 7710.2.1 Values for <FREQ>
7810.2.2 Examples 7910.3 Retrieving Transactions Generated by a Recurring Model 8010.4
Modifying and Canceling Individual Transactions 8010.5 Modifying and Canceling Recurring
Models 8010.5.1 Examples 81
<ol>
<li><a NAME="_Toc380493239"><font SIZE="6" FACE="Arial">Overview</font></a> </li>
<li><a NAME="_Toc380493240"><font SIZE="5" FACE="Arial">Introduction</font></a> </li>
</ol>
<p><font SIZE="2">Open Financial Exchange is a broad-based framework for exchanging
financial data and instructions between customers and their financial institutions. It
allows institutions to connect directly to their customers without requiring an
intermediary. <br>
<br>
</font></p>
<p><font SIZE="2">Open Financial Exchange is an open specification that anyone can
implement: any financial institution, transaction processor, software developer or other
party. It uses widely accepted open standards for data formatting (such as SGML),
connectivity (such as TCP/IP and HTTP), and security (such as SSL).</font> </p>
<p><font SIZE="2">Open Financial Exchange defines the request and response messages used
by each financial service as well as the common framework and infrastructure to support
the communication of those messages. This specification does not describe any specific
product implementation.</font>
<ol>
<li><a NAME="_Toc380493241"><font SIZE="4" FACE="Arial">Design Principles</font></a> </li>
</ol>
<p><font SIZE="2">The following principles were used in designing Open Financial Exchange:</font>
</p>
<p><font SIZE="1" FACE="Wingdings">l</font><font SIZE="2"> </font><font SIZE="2"
FACE="Arial"><b>Broad</b> <b>Range of Financial Activities</b></font><font SIZE="2"> -
Open Financial Exchange provides support for a <i><b>broad</b></i> range of financial
activities. Open Financial Exchange 1.0 specifies the following services:</font> </p>
<p><font SIZE="1" FACE="Wingdings">n</font><font SIZE="2"> Bank statement download</font> </p>
<p><font SIZE="1" FACE="Wingdings">n</font><font SIZE="2"> Credit card statement download</font>
</p>
<p><font SIZE="1" FACE="Wingdings">n</font><font SIZE="2"> Funds transfers including
recurring transfers</font> </p>
<p><font SIZE="1" FACE="Wingdings">n</font><font SIZE="2"> Consumer payments, including
recurring payments</font> </p>
<p><font SIZE="1" FACE="Wingdings">n</font><font SIZE="2"> Business payments, including
recurring payments</font> </p>
<p><font SIZE="1" FACE="Wingdings">n</font><font SIZE="2"> Brokerage and mutual fund
statement download, including transaction history, current holdings and balances</font> </p>
<p><font SIZE="1" FACE="Wingdings">l</font><font SIZE="2"> </font><font SIZE="2"
FACE="Arial"><b>Broad</b> <b>Range of Financial Institutions</b></font><font SIZE="2"> -
Open Financial Exchange supports communication with a <i><b>broad</b></i> range of
financial institutions (FIs), including:</font> </p>
<p><font SIZE="1" FACE="Wingdings">n</font><font SIZE="2"> Banks</font> </p>
<p><font SIZE="1" FACE="Wingdings">n</font><font SIZE="2"> Brokerage houses</font> </p>
<p><font SIZE="1" FACE="Wingdings">n</font><font SIZE="2"> Merchants</font> </p>
<p><font SIZE="1" FACE="Wingdings">n</font><font SIZE="2"> Processors</font> </p>
<p><font SIZE="1" FACE="Wingdings">n</font><font SIZE="2"> Financial advisors</font> </p>
<p><font SIZE="1" FACE="Wingdings">n</font><font SIZE="2"> Government agencies</font> </p>
<p><font SIZE="1" FACE="Wingdings">l</font><font SIZE="2"> </font><font SIZE="2"
FACE="Arial"><b>Broad</b> <b>Range of Front-End applications</b></font><font SIZE="2"> -
Open Financial Exchange supports a <i><b>broad </b></i>range of front-end applications
covering all types of financial activities running on all types of platforms, including
Web-based applications.</font> </p>
<p><font SIZE="1" FACE="Wingdings">l</font><font SIZE="2"> </font><b><font SIZE="2"
FACE="Arial">Extensible</font></b><font SIZE="2"> - Open Financial Exchange has been
designed to allow the easy addition of new services. Future versions will include support
for many new services.</font> </p>
<p><font SIZE="1" FACE="Wingdings">l</font><font SIZE="2"> </font><b><font SIZE="2"
FACE="Arial">Open</font></b><font SIZE="2"> - This specification is publicly available.
You can build client and server applications using the Open Financial Exchange protocols
independent of any specific technology, product, or company.</font> </p>
<p><font SIZE="1" FACE="Wingdings">l</font><font SIZE="2"> </font><b><font SIZE="2"
FACE="Arial">Multiple Client Support</font></b><font SIZE="2"> - Open Financial Exchange
allows a user to use multiple client applications to access the same data at a financial
institution. With the popularity of the World Wide Web, customers are increasingly more
likely to use multiple applications-either desktop-based or Web-based-to perform financial
activities. For example, a customer can track personal finances at home with a desktop
application and occasionally pay bills while at work with a Web-based application. The use
of data synchronization to support multiple clients is a key innovation in Open Financial
Exchange.</font> </p>
<p><font SIZE="1" FACE="Wingdings">l</font><font SIZE="2"> </font><b><font SIZE="2"
FACE="Arial">Robust</font></b><font SIZE="2"> - Open Financial Exchange will be used for
executing important financial transactions and for communicating important financial
information. Assuring users that transactions are executed and information is correct is
crucial. Open Financial Exchange provides robust protocols for error recovery.</font> </p>
<p><font SIZE="1" FACE="Wingdings">l</font><font SIZE="2"> </font><b><font SIZE="2"
FACE="Arial">Secure</font></b><font SIZE="2"> - Open Financial Exchange provides a
framework for building secure online financial services. In Open Financial Exchange,
security encompasses authentication of the parties involved, as well as secrecy and
integrity of the information being exchanged.</font> </p>
<p><font SIZE="1" FACE="Wingdings">l</font><font SIZE="2"> </font><b><font SIZE="2"
FACE="Arial">Batch & Interactive</font></b><font SIZE="2"> - The design of request and
response messages in Open Financial Exchange is for use in either batch or interactive
style of communication. Open Financial Exchange provides for applying a single
authentication context to multiple requests in order to reduce the overhead of user
authentication.</font> </p>
<p><font SIZE="1" FACE="Wingdings">l</font><font SIZE="2"> </font><b><font SIZE="2"
FACE="Arial">International</font></b><font SIZE="2"> </font><b><font SIZE="2" FACE="Arial">Support</font></b><font
SIZE="2"> - Open Financial Exchange is designed to supply financial services throughout
the world. It supports multiple currencies, country-specific extensions, and different
forms of encoding such as UNICODE.</font> </p>
<p><font SIZE="1" FACE="Wingdings">l</font><font SIZE="2"> </font><b><font SIZE="2"
FACE="Arial">Platform Independent</font></b><font SIZE="2"> -Open Financial Exchange can
be implemented on a wide variety of front-end client devices, including those running
Windows 3.1, Windows 95, Windows NT, Macintosh, or UNIX. It also supports a wide variety
of Web-based environments, including those using HTML, Java, JavaScript, or ActiveX.
Similarly on the back-end, Open Financial Exchange can be implemented on a wide variety of
server systems, including those running UNIX, Windows NT, or OS/2.</font> </p>
<p><font SIZE="1" FACE="Wingdings">l</font><font SIZE="2"> </font><b><font SIZE="2"
FACE="Arial">Transport Independent</font></b><font SIZE="2"> - Open Financial Exchange is
independent of the data communication protocol used to transport the messages between the
client and server computers. Open Financial Exchange 1.0 will use HTTP.</font>
<ol>
<li><font SIZE="5" FACE="Arial"><a NAME="_Toc380493242">Open Financial Exchange </a>at a
Glance</font> </li>
</ol>
<p><font SIZE="2">The design of Open Financial Exchange is as a client and server system.
An end-user uses a client application to communicate with a server at a financial
institution. The form of communication is requests from the client to the server and
responses from the server back to the client.</font> </p>
<p><font SIZE="2">Open Financial Exchange uses the Internet Protocol (IP) suite to provide
the communication channel between a client and a server. IP protocols are the foundation
of the public Internet and a private network can also use them.</font>
<ol>
<li><a NAME="_Toc380493243"><font SIZE="4" FACE="Arial">Data Transport</font></a> </li>
</ol>
<p><font SIZE="2">Clients use the HyperText Transport Protocol (HTTP) to communicate to an
Open Financial Exchange server. The World Wide Web throughout uses the same HTTP protocol.
In principle, a financial institution can use any off-the-shelf web server to implement
its support for Open Financial Exchange.</font> </p>
<p><font SIZE="2">To communicate by means of Open Financial Exchange over the Internet,
the client must establish an Internet connection. This connection can be a dial-up
Point-to-Point Protocol (PPP) connection to an Internet Service Provider (ISP) or a
connection over a local area network that has a gateway to the Internet.</font> </p>
<p><font SIZE="2">Clients use the HTTP POST command to send a request to the previously
acquired Uniform Resource Locator (URL) for the desired financial institution. The URL
presumably identifies a Common Gateway Interface (CGI) or other process on an FI server
that can accept Open Financial Exchange requests and produce a response.</font> </p>
<p><font SIZE="2">The POST identifies the data as being of type application/x-ofx. Use
application/x-ofx as the return type as well. Fill in other fields per the HTTP 1.0 spec.
Here is a typical request:</font> </p>
<pre>
<font SIZE="1">POST http://www.fi.com/ofx.cgi HTTP/1.0
User-Agent:MyApp 5.0
Content-Type: application/x-ofx
Content-Length: 1032
OFXHEADER:100
</font><font
SIZE="2">DATA:OFXSGML
VERSION:100
SECURITY:1
ENCODING:USASCII
<OFX>
... Open Financial Exchange requests ...
</OFX></font>
</pre>
<p><font SIZE="2">A blank line defines the separation between the HTTP headers and the
start of the actual Open Financial Exchange data. A blank line also separates the Open
Financial Exchange headers and the actual response. (See Chapter 2, for more information.)</font>
</p>
<p><font SIZE="2">The structure of a response is similar to the request, with the first
line containing the standard HTTP result, as shown next. The content length is given in
bytes.</font> </p>
<pre>
<font SIZE="1">HTTP 1.0 200 OK
Content-Type: application/x-ofx
Content-Length: 8732
OFXHEADER:100
</font><font
SIZE="2">DATA:OFXSGML
VERSION:100
SECURITY:1
ENCODING:USASCII
<OFX>
... Open Financial Exchange responses ...
</OFX></font>
</pre>
<ol>
<li><font SIZE="4" FACE="Arial"><a NAME="_Toc380493244">Request and Response</a> Model</font>
</li>
</ol>
<p><font SIZE="2">The basis for Open Financial Exchange is the request and response model.
One or more requests can be batched in a single file. This file typically includes a
signon request and one or more service-specific requests. An FI server will process all of
the requests and return a single response file. This batch model lends itself to Internet
transport as well as other off-line transports. Both requests and responses are plain text
files, formatted using a grammar based on Standard Generalized Markup Language (SGML).
Open Financial Exchange is syntactically similar to HyperText Markup Language (HTML),
featuring tags to identify and delimit the data. The use of a tagged data format allows
Open Financial Exchange to evolve over time while continuing to support older clients and
servers.</font> </p>
<p><font SIZE="2">Here is a simplified example of an Open Financial Exchange request file.
(This example does not show the Open Financial Exchange headers and the indentation is
only for readability.) For complete details, see the more complete examples throughout
this specification.</font> </p>
<p><OFX> <!-- Begin request data --> <SIGNONMSGSRQV1> <SONRQ>
<!-- Begin signon --> <DTCLIENT>19961029101000 <!-- Oct. 29, 1996, 10:10:00
am --> <USERID>123-45-6789 <!-- User ID (that is, SSN) -->
<USERPASS>MyPassword <!-- Password (SSL encrypts whole) -->
<LANGUAGE>ENG <!-- Language used for text --> <FI> <!-- ID of
receiving institution --> <ORG>NCH <!-- Name of ID owner -->
<FID>1001 <!-- Actual ID --> </FI> <APPID>MyApp <APPVER>0500
</SONRQ> <!-- End of signon --> </SIGNONMSGSRQV1> <BANKMSGSRQV1>
<STMTTRNRQ> <!-- First request in file --> <TRNUID>1001 <STMTRQ>
<!-- Begin statement request --> <BANKACCTFROM> <!-- Identify the account
--> <BANKID>121099999 <!-- Routing transit or other FI ID -->
<ACCTID>999988 <!-- Account number --> <ACCTTYPE>CHECKING <!--
Account type --> </BANKACCTFROM> <!-- End of account ID --> <INCTRAN>
<!-- Begin include transaction --> <INCLUDE>Y <!-- Include transactions
--> </INCTRAN> <!-- End of include transaction --> </STMTRQ> <!--
End of statement request --> </STMTTRNRQ> <!-- End of first request -->
</BANKMSGSRQV1></OFX> <!-- End of request data --><font SIZE="2">The
response format follows a similar structure. Although a response such as a statement
response contains all of the details of each transaction, each element is identified using
tags.</font> </p>
<p><font SIZE="2">The key rule of Open Financial Exchange syntax is that each tag is
either an element or an aggregate. Data follows its element tag. An aggregate tag begins a
compound tag sequence, which must end with a matching tag; for example, <AGGREGATE>
... </AGGREGATE>. </font></p>
<p><font SIZE="2">The actual file Open Financial Exchange sends is without any extra white
space between tags.</font>
<ol>
<li><a NAME="_Toc380493245"><font SIZE="5" FACE="Arial">Conventions</font></a> </li>
</ol>
<p><font SIZE="2">The conventions used in the detailed descriptions include: </font>
<ul>
<li><font SIZE="2">Required tags are in <b>bold</b>. Regular face indicates tags that are
optional. Required means that a client will always include a tag in a request, and a
server must always include a tag in a response.</font> </li>
<li><font SIZE="2"><i>Italic </i>shows a required or optional aggregate from a set of
possible aggregates. </font></li>
<li><font SIZE="2">Required tags occur once unless noted as one or more in the description,
in which case the specification allows multiple occurrences. </font></li>
<li><font SIZE="2">Optional tags occur once if present unless noted as zero or more in the
description, in which case the specification allows multiple occurrences.</font> </li>
<li><font SIZE="2">Allowable specific values are listed, where applicable.</font> </li>
<li><font SIZE="2">A-<i>n</i> or N-<i>n</i>, specify those values that take general
alphanumeric or pure numeric type values, where <i>n</i> indicates the maximum size. </font></li>
<li><font SIZE="2">References to certain common value types, such as a dollar amount, are by
name. Chapter 3 lists value types that can be referenced by name.</font> </li>
</ul>
<table BORDER="1">
<tr>
<td BGCOLOR="#000000" WIDTH="162"><i><font SIZE="1">Tag</font></i> </td>
<td BGCOLOR="#000000" WIDTH="336"><i><font SIZE="2">Description</font></i> </td>
</tr>
<tr>
<td WIDTH="162"><b><font SIZE="1"><REQUIREDTAG></font></b> </td>
<td WIDTH="336"><font SIZE="2">Required tag (1 or more)</font> </td>
</tr>
<tr>
<td WIDTH="162"><b><font SIZE="1"><REQUIREDTAG2></font></b> </td>
<td WIDTH="336"><font SIZE="2">Required tag that occurs only once </font></td>
</tr>
<tr>
<td WIDTH="162"><font SIZE="1"><OPTIONALTAG> </font></td>
<td WIDTH="336"><font SIZE="2">Optional tag; this particular one can occur multiple times
(0 or more) </font></td>
</tr>
<tr>
<td WIDTH="162"><font SIZE="1"><SPECIFIC></font></td>
<td WIDTH="336"><font SIZE="2">Values are A, B, and C</font> </td>
</tr>
<tr>
<td WIDTH="162"><font SIZE="1"><ALPHAVALUE></font></td>
<td WIDTH="336"><font SIZE="2">Takes an alphanumeric value up to 32 characters,<i> A-32</i></font>
</td>
</tr>
</table>
<ol>
<li><a NAME="_Toc380493246"><font SIZE="6" FACE="Arial">Structure</font></a> </li>
</ol>
<p><font SIZE="2">This chapter describes the basic structure of an Open Financial Exchange
request and response. Structure includes headers, basic syntax, and the Signon request and
response. This chapter also describes how Open Financial Exchange encodes external data,
such as bit maps.</font> </p>
<p><font SIZE="2">Open Financial Exchange data consists of some headers plus one or more
Open Financial Exchange data blocks. Each block consists of a signon message and zero or
more additional messages. When sent over the internet using HTTP, standard HTTP and
multi-part MIME headers and formats surround the Open Financial Exchange data. A simple
file that contained only Open Financial Exchange data would have the following form:</font>
</p>
<pre>
<font SIZE="1">HTTP headers
MIME type application/x-ofx
Open Financial Exchange headers
Open Financial Exchange SGML block 1</font>
</pre>
<p><font SIZE="2">A more complex file that contained multiple Open Financial Exchange data
blocks and additional Open Financial Exchange data would have this form:</font> </p>
<pre>
<font SIZE="1">HTTP headers
MIME type multipart/x-mixed-replace; boundary =--boundary-
---boundary---
MIME type application/x-ofx
</font><font
SIZE="2"> Open Financial Exchange headers
Open Financial Exchange SGML block 1
Open Financial Exchange SGML block 2
---boundary---
MIME type image/jpeg
FI logo</font>
</pre>
<ol>
<li><a NAME="_Toc380493247"><font SIZE="5" FACE="Arial">HTTP Headers</font></a> </li>
</ol>
<p><font SIZE="2">Data delivered by way of HTTP places the standard HTTP result code on
the first line. HTTP defines a number of status codes. Servers can return any standard
HTTP result. However, FIs should expect clients to collapse these codes into the following
three cases:</font> </p>
<table BORDER="1">
<tr>
<td BGCOLOR="#000000" WIDTH="84"><i><font SIZE="1">Code</font></i> </td>
<td BGCOLOR="#000000" WIDTH="96"><i><font SIZE="2">Meaning</font></i> </td>
<td BGCOLOR="#000000" WIDTH="312"><i><font SIZE="2">Action</font></i> </td>
</tr>
<tr>
<td WIDTH="84"><font SIZE="1">200</font></td>
<td WIDTH="96"><font SIZE="2">OK</font> </td>
<td WIDTH="312"><font SIZE="2">The request was processed and a valid Open Financial
Exchange result is returned.</font> </td>
</tr>
<tr>
<td WIDTH="84"><font SIZE="1">400s</font></td>
<td WIDTH="96"><font SIZE="2">Bad request</font> </td>
<td WIDTH="312"><font SIZE="2">The request was invalid and was not processed. Clients will
report an internal error to the user.</font> </td>
</tr>
<tr>
<td WIDTH="84"><font SIZE="1">500s</font></td>
<td WIDTH="96"><font SIZE="2">Server error</font> </td>
<td WIDTH="312"><font SIZE="2">The server is unavailable. Clients should advise the user
to retry shortly.</font> </td>
</tr>
</table>
<p><i><b>NOTE:</b> Open Financial Exchange returns a code 400 only if it cannot parse the
file. Open Financial Exchange handles content errors such as wrong PIN, or invalid
account, by returning a valid Open Financial Exchange response along with code 200.</i> </p>
<p>Open Financial Exchange requires the following HTTP standard headers: </p>
<table BORDER="1">
<tr>
<td BGCOLOR="#000000" WIDTH="84"><i><font SIZE="1">Code</font></i> </td>
<td BGCOLOR="#000000" WIDTH="96"><i><font SIZE="2">Value</font></i> </td>
<td BGCOLOR="#000000" WIDTH="312"><i><font SIZE="2">Explanation</font></i> </td>
</tr>
<tr>
<td WIDTH="84"><font SIZE="1">Content-type</font></td>
<td WIDTH="96"><font SIZE="2">application/x-ofx</font> </td>
<td WIDTH="312"><font SIZE="2">The MIME type for Open Financial Exchange</font> </td>
</tr>
<tr>
<td WIDTH="84"><font SIZE="1">Content-length</font></td>
<td WIDTH="96"><font SIZE="2">length</font> </td>
<td WIDTH="312"><font SIZE="2">Length of the data after removing HTTP headers</font> </td>
</tr>
</table>
<pre>
</pre>
<p><font SIZE="2">When responding with multi-part MIME, the main type will be
multi-part/x-mixed-replace; <br>
one of the parts will use application/x-ofx.</font>
<ol>
<li><a NAME="_Toc380493248"><font SIZE="5" FACE="Arial">Open Financial Exchange Headers</font></a>
</li>
</ol>
<p><font SIZE="2">The intent of Open Financial Exchange is for use with a variety of
transports and to provide sufficient version control capabilities for future expansion. To
support this goal, the contents of an Open Financial Exchange file consist of a simple set
of headers followed by contents defined by that header. "File format" means the
entire content after removal of any transport headers. The HTTP transport described in
this document, means without the HTTP and MIME headers.</font> </p>
<p><font SIZE="2">The Open Financial Exchange headers are in a simple <i>tag:value</i>
syntax and terminated by a blank line. Open Financial Exchange always sends headers
unencrypted, even if there is application-level encryption in use for the remaining
contents. The first entry will always be OFXHEADER with a version number. This entry will
help identify the contents as an Open Financial Exchange file, and provides the version of
the Open Financial Exchange headers that follow (not of the content itself). For example:</font>
</p>
<pre>
<font SIZE="1">OFXHEADER:100</font>
</pre>
<p><font SIZE="2">This document defines version 1.0 of the headers to contain at least the
following additional tags:</font> </p>
<pre>
<font SIZE="1">DATA:OFXSGML
VERSION:100
SECURITY:
ENCODING:
</font><font SIZE="2">CHARSET:
COMPRESSION:
OLDFILEUID:
NEWFILEUID:</font>
</pre>
<p><font SIZE="2">The data tag identifies the contents as being in OFX SGML form. VERSION
identifies the version type as OFXSGML data. In the case of OFXSGML, it translates to the
version of the Document Type Definition (DTD) that it uses for parsing. The ENCODING and
CHARSET tags define the interpretation of the character data. See Chapter 5,
"International Support" for more information on these tags. Chapter 4 describes
the security tag. A future version of this specification will define compression.</font> </p>
<p><font SIZE="2">Open Financial Exchange uses OLDFILEUID and NEWFILEUID to support error
recovery. They are not present when clients are not requesting error recovery. (See
Chapter 6, "Data Synchronization")</font> </p>
<p><font SIZE="2">A blank line follows the last tag. Then (for type OFXSGML), the
SGML-readable data begins with the <OFX> tag.</font> </p>
<p><font SIZE="2"><i><b>NOTE:</b> Here, VERSION provides the overall version of the DTD.
The <OFX> block describes the specific message set versions used, shown later in
this chapter.</i></font>
<ol>
<li><a NAME="_Toc380493249"><font SIZE="4" FACE="Arial">The Meaning of Version Numbers</font></a>
</li>
</ol>
<p><font SIZE="2">The OFXHEADER value should only change its major number if an existing
client is unable to process the new header. This can occur because of a complete syntax
change in a header, or a significant change in the semantics of an existing tag-not the
entire response. You can add new tags as long as clients can function without
understanding them.</font> </p>
<p><font SIZE="2">You should add new values for a data tag only when you introduce an
entirely new syntax. In the case of OFXSGML, a new syntax would have to be non-SGML
compliant to warrant a new data value. It is possible that there will be more than one
syntax in use at the same time to meet different needs.</font> </p>
<p><font SIZE="2">The intent of the header version tag is to identify syntactic changes.
In the case of OFXSGML, this corresponds to the DTD. Purely for identification purposes,
each change will increment the minor number of the version tag. If you introduce an
incompatible change so that an older DTD can not parse the file, the major number will
change. See the general discussion of message sets and version control, later in this
chapter.</font>
<ol>
<li><a NAME="_Toc380493250"><font SIZE="5" FACE="Arial">SGML Details</font></a> </li>
<li><a NAME="_Toc380493251"><font SIZE="4" FACE="Arial">Compliance</font></a> </li>
</ol>
<p><font SIZE="2">SGML is the basis for Open Financial Exchange. There is a DTD that
formally defines the SGML wire format. However, Open Financial Exchange is not completely
SGML-<i>compliant</i> because the specification allows unrecognized tags to be present. It
requires clients and servers to skip over the unrecognized material. That is, if
<XYZ>qqq</XYZ> appeared and a client or server cannot recognize <XYZ>,
the server should ignore that tag and its enclosed data. A fully-compliant SGML parser
would not <i>validate</i> an Open Financial Exchange document if it contained any tags
that the DTD does not define.</font> </p>
<p><font SIZE="2">Although SGML is the basis for the specification, and the specification
is largely compliant with SGML, do not assume Open Financial Exchange supports any SGML
features not documented in this specification. The intent is to allow parsing to be as
simple as possible, while retaining compatibility with the SGML world.</font>
<ol>
<li><a NAME="_Toc380493252"><font SIZE="4" FACE="Arial">Special Characters</font></a> </li>
</ol>
<p><font SIZE="2">The following characters are special to SGML. Use the given alternative
sequence to represent them:</font> </p>
<table BORDER="1">
<tr>
<td BGCOLOR="#000000" WIDTH="162"><i><font SIZE="1">Character</font></i> </td>
<td BGCOLOR="#000000" WIDTH="336"><i><font SIZE="2">Escape sequence</font></i> </td>
</tr>
<tr>
<td WIDTH="162"><font SIZE="1">< (less than)</font></td>
<td WIDTH="336"><font SIZE="2">&lt;</font> </td>
</tr>
<tr>
<td WIDTH="162"><font SIZE="1">> (greater than)</font></td>
<td WIDTH="336"><font SIZE="2">&gt;</font></td>
</tr>
<tr>
<td WIDTH="162"><font SIZE="1">& (ampersand)</font></td>
<td WIDTH="336"><font SIZE="2">&amp;</font> </td>
</tr>
</table>
<p>For example, the string "AT&amp;T" encodes "AT&T." </p>
<p>A special case applies in specific tags that can accept HTML-formatted strings, such as
e-mail records. These accept SGML marked section syntax to hide the HTML from the Open
Financial Exchange parser. You must prefix strings with "<![ CDATA ["and
suffixed with"]]>." Within these bounds, treat the above characters literally
without an escape. See the Chapter 9 for an example.
<ol>
<li><a NAME="_Toc380493253"><font SIZE="5" FACE="Arial">Open Financial Exchange SGML
Structure</font></a> </li>
<li><a NAME="_Toc380493254"><font SIZE="4" FACE="Arial">Overview</font></a> </li>
</ol>
<p><font SIZE="2">Open Financial Exchange hierarchically organizes request and response
blocks:</font> </p>
<p><font SIZE="2">Top Level <OFX><br>
Message Set and Version <<i>XXX</i>MSGSVn><br>
Synchronization Wrappers <YYYSYNCRQ>, <YYYSYNCRS> <br>
Transaction Wrappers <YYYTRNRQ>, <YYYTRNRS><br>
Specific requests and responses</font> </p>
<p><font SIZE="2">The following sections describe each of these levels.</font>
<ol>
<li><a NAME="_Toc380493255"><font SIZE="4" FACE="Arial">Top Level</font></a> </li>
</ol>
<p><font SIZE="2">An Open Financial Exchange request or response has the following
top-level form:</font> </p>
<table BORDER="1">
<tr>
<td BGCOLOR="#000000" WIDTH="162"><i><font SIZE="1">Tag</font></i> </td>
<td BGCOLOR="#000000" WIDTH="336"><i><font SIZE="2">Description</font></i> </td>
</tr>
<tr>
<td WIDTH="162"><font SIZE="1"><<b>OFX</b>></font></td>
<td WIDTH="336"><font SIZE="2">Opening tag</font></td>
</tr>
<tr>
<td WIDTH="162"><font SIZE="1">... Open Financial Exchange requests or responses ...</font>
</td>
<td WIDTH="336"><font SIZE="2">0 or more transaction requests and responses inside
appropriate message set aggregates</font> </td>
</tr>
<tr>
<td WIDTH="162"><font SIZE="1"></<b>OFX</b>></font></td>
<td WIDTH="336"><font SIZE="2">Closing tag for the Open Financial Exchange record</font> </td>
</tr>
</table>
<p>This chapter specifies the order of requests and responses. </p>
<p>A single file can contain multiple <OFX> ... </OFX> blocks. A typical use
of multiple blocks is to request in a single file information associated with different
users.
<ol>
<li><a NAME="_Toc380493256"><font SIZE="4" FACE="Arial">Messages</font></a> </li>
</ol>
<p><font SIZE="2">A message is the unit of work in Open Financial Exchange. It refers to a
request and response pair, and the status codes associated with that response. For
example, the message to download a bank statement consists of the request <STMTRQ>
and the response <STMTRS>. In addition, with the exception of the signon message,
each message includes a <i>transaction wrapper</i>. These aggregates add a transaction
unique ID <TRNUID>, and for responses, a <STATUS> aggregate, to the basic
request and response. </font></p>
<p><font SIZE="2">For messages subject to synchronization (see Chapter 6), a third layer
of aggregates is also part of a message definition: a synchronization request and
response. These add a token and, in some cases, other information to the transactions. </font></p>
<p><font SIZE="2">Open Financial Exchange uses the following naming where the <i>XXX</i>
message includes:</font>
<ul>
<li><font SIZE="2">Basic request <<i>XXX</i><b>RQ</b>> and response <<i>XXX</i><b>RS</b>></font>
</li>
<li><font SIZE="2">Transaction wrapper <<i>XXX</i><b>TRNRQ</b>> and <<i>XXX</i><b>TRNRS</b>></font>
</li>
<li><font SIZE="2">If needed, synchronization wrapper <<i>XXX</i><b>SYNCRQ</b>> and
<<i>XXX</i><b>SYNCRS</b>></font> </li>
</ul>
<p><font SIZE="2">In a few cases, a small number of related basic requests and responses
share a transaction and synchronization wrapper. The term message will still apply to each
request and response; only the naming scheme will not hold in those cases.</font>
<ol>
<li><a NAME="_Toc380493257"><font SIZE="4" FACE="Arial">Message Sets and Version Control</font></a>
</li>
</ol>
<p><font SIZE="2">Message sets are collections of messages. Generally they form all or
part of what a user would consider a <i>service</i>, something for which they might have
signed up, such as "banking." Message sets are the basis of version control,
routing, and security. They are also the basis for the required ordering in Open Financial
Exchange files.</font> </p>
<p><font SIZE="2">Within an Open Financial Exchange block, Open Financial Exchange
organizes messages by message set. A message set can appear at most once within an Open
Financial Exchange block. All messages from a message set must be from the same version of
that message set.</font> </p>
<p><font SIZE="2">For each message set of <i>XXX</i> and version <i>n</i>, there exists an
aggregate named <<i>XXX</i>MSGSV<i>n</i>>. (Compare with <<i>XXX</i>MSGSETV<i>n</i>>
in Chapter 7.) All of the messages from that message set must be inside the appropriate
message set aggregate. In the following example, the Open Financial Exchange block
contains a signon request inside the signon message set, and two statement requests and a
transfer request inside the bank message set.</font> </p>
<pre>
<font SIZE="1"><OFX>
<SIGNONMSGSRQV1> <!-- Signon message set -->
<SONRQ> <!-- Signon message -->
...
</SONRQ>
</SIGNONMSGSRQV1>
<BANKMSGSRQV1> <!-- Banking message set -->
<STMTTRNRQ> <!-- Statement request -->
...
</STMTTRNRQ>
<STMTTRNRQ> <!-- Another stmt request -->
...
</STMTTRNRQ>
<INTRATRNRQ> <!-- Intra-bank transfer request -->
...
</INTRATRNRQ>
</BANKMSGSRQV1>
</OFX></font>
</pre>
<p><font SIZE="2">Message sets, if used at all, must appear in the following order:</font>
<ul>
<li><font SIZE="2">Signon</font> </li>
<li><font SIZE="2">Signup</font> </li>
<li><font SIZE="2">Banking</font> </li>
<li><font SIZE="2">Credit card statements</font> </li>
<li><font SIZE="2">Investment statements</font> </li>
<li><font SIZE="2">Interbank funds transfers</font> </li>
<li><font SIZE="2">Wire funds transfers</font> </li>
<li><font SIZE="2">Payments</font> </li>
<li><font SIZE="2">General e-mail</font> </li>
<li><font SIZE="2">Investment security list</font> </li>
<li><font SIZE="2">FI Profile</font> </li>
</ul>
<p><font SIZE="2">The definition of each message set can further prescribe an order of its
messages within that message set.</font>
<ol>
<li><a NAME="_Toc380493258"><font SIZE="4" FACE="Arial">Transactions</font></a> </li>
</ol>
<p><font SIZE="2">Other than the signon message, each request is made as a transaction.
Transactions contain a client-assigned globally unique ID, optional client-supplied
pass-back data, and then the record for the specific request. A transaction similarly
wraps each response. The response transaction returns the client ID sent in the request,
along with a status message, the pass-back data if present, and the specific response
record. This technique allows a client to track responses against requests.</font> </p>
<p><font SIZE="2">The <STATUS> aggregate, defined in Chapter 3, provides feedback on
the processing of the request. If the <SEVERITY> of the status is ERROR, the server
provides no specific response record. Otherwise, the response will be complete even though
some warning might have occurred.</font> </p>
<p><font SIZE="2">Clients can send additional information in <CLTCOOKIE> that
servers will return in the response. This allows clients that do not maintain state, and
thus do not save TRNUIDs, to cause some additional descriptive information to be present
in the response. For example, a client might identify a request as relating to a user or a
spouse.</font> </p>
<p><font SIZE="2">In some countries some transactions require a customer-supplied
authorization number for each transaction. In those countries, the <TAN> element
provides the means to pass this information to servers. As Open Financial Exchange is
implemented in each country, the specification will define the specific requirements for
the use of <TAN> in each country.</font> </p>
<p><font SIZE="2">A typical request is as follows:</font> </p>
<table BORDER="1">
<tr>
<td BGCOLOR="#000000" WIDTH="132"><i><font SIZE="1">Tag</font></i> </td>
<td BGCOLOR="#000000" WIDTH="366"><i><font SIZE="2">Description</font></i> </td>
</tr>
<tr>
<td WIDTH="132"><b><font SIZE="1"><<b><i>XXX</i>TRNRQ></b></font></b> </td>
<td WIDTH="366"><font SIZE="2">Transaction-request aggregate</font> </td>
</tr>
<tr>
<td WIDTH="132"><b><font SIZE="1"><TRNUID></font></b></td>
<td WIDTH="366"><font SIZE="2">Client-assigned globally unique ID for this transaction <i>trnuid</i></font>
</td>
</tr>
<tr>
<td WIDTH="132"><font SIZE="1"><CLTCOOKIE></font></td>
<td WIDTH="366"><font SIZE="2">Data to be echoed in the transaction response <i>A-32</i></font>
</td>
</tr>
<tr>
<td WIDTH="132"><font SIZE="1"><TAN></font></td>
<td WIDTH="366"><font SIZE="2">Transaction authorization number; used in some countries
with some types of transactions. Country-specific documentation will define messages that
require a TAN, <i>A-80</i></font> </td>
</tr>
<tr>
<td WIDTH="132"><font SIZE="1">specific request</font></td>
<td WIDTH="366"><font SIZE="2">Aggregate for the specific request</font> </td>
</tr>
<tr>
<td WIDTH="132"><b><font SIZE="1"></<b><i>XXX</i>TRNRQ></b></font></b> </td>
<td WIDTH="366"> </td>
</tr>
</table>
<p>A typical response is as follows:<br>
</p>
<table BORDER="1">
<tr>
<td BGCOLOR="#000000" WIDTH="132"><i><font SIZE="1">Tag</font></i> </td>
<td BGCOLOR="#000000" WIDTH="366"><i><font SIZE="2">Description</font></i> </td>
</tr>
<tr>
<td WIDTH="132"><b><font SIZE="1"><<b><i>XXX</i>TRNRS></b></font></b> </td>
<td WIDTH="366"><font SIZE="2">Transaction-response aggregate</font> </td>
</tr>
<tr>
<td WIDTH="132"><b><font SIZE="1"><TRNUID></font></b></td>
<td WIDTH="366"><font SIZE="2">Client-assigned globally unique ID for this transaction, <i>trnuid</i></font>
</td>
</tr>
<tr>
<td WIDTH="132"><font SIZE="1"><CLTCOOKIE></font></td>
<td WIDTH="366"><font SIZE="2">Client-provided data, <b>REQUIRED</b> if provided in
request, <i>A-32</i></font> </td>
</tr>
<tr>
<td WIDTH="132"><b><font SIZE="1"><STATUS></font></b></td>
<td WIDTH="366"><font SIZE="2">Status aggregate</font></td>
</tr>
<tr>
<td WIDTH="132"><b><font SIZE="1"></STATUS></font></b> </td>
<td WIDTH="366"> </td>
</tr>
<tr>
<td WIDTH="132"><font SIZE="1">response record</font></td>
<td WIDTH="366"><font SIZE="2">Aggregate for the specific response</font> </td>
</tr>
<tr>
<td WIDTH="132"><b><font SIZE="1"></<b><i>XXX</i>TRNRS></b></font></b> </td>
<td WIDTH="366"> </td>
</tr>
</table>
<ol>
<li><a NAME="_Toc380493259"><font SIZE="5" FACE="Arial">The Signon Message Set</font></a> </li>
</ol>
<p><font SIZE="2">The Signon message set includes the signon message and the PIN change
message, and must appear in that order. The <SIGNONMSGSRQV1> and
<SIGNONMSGSRSV1> aggregates wrap the message.</font>
<ol>
<li><a NAME="_Toc380493260"><font SIZE="4" FACE="Arial">Signon <SONRQ> <SONRS></font></a>
</li>
</ol>
<p><font SIZE="2">The signon record identifies and authenticates a user to an FI. It also
includes information about the application making the request, because some services might
be appropriate only for certain clients. Every Open Financial Exchange request contains
exactly one <SONRQ>. Every response must contain exactly one <SONRS> record. </font></p>
<p><font SIZE="2">Use of Open Financial Exchange presumes that FIs authenticate each
customer and then give the customer access to one or more accounts or services. If
passwords are specific to individual services or accounts, a separate Open Financial
Exchange request will be made for each distinct user ID or password required. This will
not necessarily be in a manner visible to the user. Note that some situations, such as
joint accounts or business accounts, will have multiple user IDs and multiple passwords
that can access the same account.</font> </p>
<p><font SIZE="2">FIs assign user IDs for the customer. It can be the customer's social
security number, but the client will not make any assumptions about the syntax of the ID,
add check-digits, or do similar processing.</font> </p>
<p><font SIZE="2">To improve server efficiency in handling a series of Open Financial
Exchange request files sent over a short period of time, clients can request that a server
return a <USERKEY> in the signon response. If the server provide a user key, clients
will send the <USERKEY> in instead of the user ID and password in subsequent
sessions, until the <USERKEY> expires. This allows servers to authenticate
subsequent requests more quickly.</font> </p>
<p><font SIZE="2">The client returns <SESSCOOKIE> if it sent one in a previous
<SONRS>. Servers can use this value to track client usage but cannot assume that all
requests come from a single client, nor can they deny service if they did not expect the
returned cookie. Use of a backup file, for example, would lead to an unexpected
<SESSCOOKIE> value that should nevertheless not stop a user from connecting.</font> </p>
<p><font SIZE="2">Servers can request that a consumer change his or her password by
returning status code 15000. Servers should keep in mind that only one status code can be
returned. If the current signon response status should be 15500 (invalid ID or password),
the request to change password will need to wait until an otherwise successful signon is
achieved.</font>
<ol>
<li><font SIZE="2" FACE="Arial">Record Request <SONRQ></font> </li>
</ol>
<table BORDER="1">
<tr>
<td BGCOLOR="#000000" WIDTH="132"><font SIZE="2">Tag</font></td>
<td BGCOLOR="#000000" WIDTH="366"><font SIZE="2">Description</font> </td>
</tr>
<tr>
<td WIDTH="132"><b><font SIZE="1"><SONRQ></font></b></td>
<td WIDTH="366"><font SIZE="2">Record- request aggregate</font></td>