idnits 2.17.1 draft-iesg-aukc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 364 has weird spacing: '...ount of c d ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 2019) is 1869 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 716, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 719, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 726, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 732, but no explicit reference was found in the text == Unused Reference: 'Fab1999' is defined on line 736, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in '1'. -- Duplicate reference: RFC2234, mentioned in 'RFC2234', was also mentioned in '2'. ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force (IETF) S. Fields 2 Internet Draft Retired 3 Intended status: Standards Track February 2019 4 Expires: August 2019 6 Audit Un-Known Cash 7 draft-iesg-aukc-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), 15 paragraph 3: 16 This document is subject to BCP 78 and the IETF Trust's Legal 17 Provisions Relating to IETF Documents 18 (https://trustee.ietf.org/license-info) in effect on the date of 19 publication of this document. Please review these documents 20 carefully, as they describe your rights and restrictions with 21 respect to this document. Code Components extracted from this 22 document must include Simplified BSD License text as described in 23 Section 4.e of the Trust Legal Provisions and are provided 24 without warranty as described in the Simplified BSD License. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on August 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. 56 Abstract 58 The issue concerns auditing financial records from several sources 59 over time. To validate proper legal money usage and flow is a 60 difficult task. Each financial institution has non-common reporting 61 methods. Seek to create a common export record to merge transactions 62 and easily sort by date , time , and institution. The first goal is 63 to create a traceability file of transactions. The second goal is to 64 create a "simple" standard record for "anyone" to sift and sort 65 records. 67 Table of Contents 69 1. Introduction...................................................3 70 2. Conventions used in this document..............................5 71 3. Explain New Record Type and Function...........................6 72 4. Protoype Data..................................................8 73 5. File Naming...................................................14 74 6. Formal Syntax.................................................15 75 7. Security Considerations.......................................19 76 8. IANA Considerations...........................................19 77 9. Conclusions...................................................19 78 10. References...................................................21 79 10.1. Normative References....................................21 80 10.2. Informative References..................................21 81 11. Acknowledgments..............................................21 82 Appendix A. Open Appendix........................................22 83 A.1. open for future..........................................22 84 A.2. open for future..........................................22 86 1. Introduction 88 Audit Financial Records 90 Each day numerous financial records and transactions occur. People 91 are put in charge as guardians or trustees for the young or old , 92 who cannot handle their own affairs. Additional people may be called 93 upon after the fact to validate and audit prior actions. 95 All financial instutions have unique and different reporting 96 methods. There is no single tool or method to extract a "common" 97 data format. Institution A may have PDF files , Institution B may 98 have XLS files. Institution C may only have paper reports. To sow 99 these records together is a large manual task. The man is working 100 for the machine. 102 Eliminate having the user reinventing the wheel each time an audit 103 is required , or manually key stroking data. Automate the process of 104 gathering data into a uniform method. 106 Current Audit Process To Get Records 108 +-------------------------------------------------------+ 109 | | 110 | | 111 | /======/ /======/ /======/ /======/ | 112 | /YEAR n/ /YEAR n/ /YEAR n/ /YEAR n/| | 113 | / ... / / ... / / ... / / ... / | | 114 | /YEAR 3/ /YEAR 3/ /YEAR 3/ /YEAR 3/ | | 115 | /YEAR 2/ /YEAR 2/ /YEAR 2/ /YEAR 2/ | | 116 | /YEAR 1/ /YEAR 1/ /YEAR 1/ /YEAR 1/ | | 117 | |=======| |=======| |=======| |=======| / | 118 | | INST. | | INST. | | INST. | | INST. | / | 119 | | A | | B | | C | | D | / | 120 | | | / | | / | | / | | / | 121 | | BANK |/ | BANK |/ | STOCK |/ | SS |/ | 122 | |=======| |=======| |=======| |=======| | 123 | | | | | | 124 | V V V V | 125 | ========================================== | 126 | =========== Gather Record Sets =========== | 127 | ========================================== | 128 | | | 129 | V | 130 | ############### | 131 | # # | 132 | # AUDIT # | 133 | # PROCESS # | 134 | # # | 135 | ############### | 136 | | 137 | | 138 +-----------------------------------------------------=-+ 140 Audit Process 142 Gather records , filter records , add records to a computer file. 143 Analyze the data , look for patterns. Report the findings. 145 2. Conventions used in this document 147 In examples, "C:" and "S:" indicate lines sent by the client and 148 server respectively. 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 In this document, these words will appear with that interpretation 155 only when in ALL CAPS. Lower case uses of these words are not to be 156 interpreted as carrying significance described in RFC 2119. 158 In this document, the characters ">>" preceding an indented line(s) 159 indicates a statement using the key words listed above. This 160 convention aids reviewers in quickly identifying or finding the 161 portions of this RFC covered by these keywords. 163 3. Explain New Record Type and Function 165 Create common record for any user. 167 Target the intended audience ! 168 Think as a non-computer expert. Think of non-computer people that do 169 jobs ; such as accounting , law enforcement , lawyers , judges , 170 banks , credit unions , estate management , and family relatives. 171 Think of simple computer users that who want to manipulate data. 172 There are numerous standards for computer data , e.g. iCal , vCard. 174 A common record type for auditing financial transactions is needed. 175 A record that will span time , time zones , dates and currencies. 177 If there is a set of records from Instution A , and another set from 178 Instution B. Each will provide data that points back to the other 179 instution. 181 Record set: 182 Record Owner A has Affiliate B 183 ( source points forward to destination ) 184 Record Owner B has Affiliate A 185 ( destination points back to source ) 187 Records should net out. 189 The left side of the handshake is always the record owner , the 190 right side is always the affiliate. 192 The record is a constant format , only the handshake flag flips 193 direction to indicate source and destination. 195 Who owns the record ? The reporting instution is the record owner of 196 the data. The affiliate is the other half of the transaction. 197 How did the money move in or out and by what method ? 199 This new proposed record will show the process and direction of how 200 the money moved. All the data should be available in today's 201 environment. 203 The audit question is: Where did the cash go ? 204 +-----------------------------------------------------------------+ 205 | | 206 | Explain Audit Steps and Flags | 207 | | 208 | Handshake | 209 | Flag | 210 | || | 211 | || Gain or Loss Flag | 212 | || || | 213 | Record || || | 214 | Record Owner Owner || || Affiliate Affiliate | 215 | Instution Account || || Instution Account | 216 | Number Number VV VV Number Number | 217 | | 218 | ----09------ ----10----- 11 12 -----13----- ----14----- | 219 | 12345678 acc12345678 => -1 99997777 acc99997777 | 220 | 99997777 acc99997777 <= +1 12345678 acc12345678 | 221 | | 222 | Constant record format from the record owner provides: | 223 | a) The instution numbers crisscross: | 224 | fields (09,10) crisscross fields (13,14) | 225 | for a given transaction (GUID). | 226 | b) The Handshake Flags (11) nets out. | 227 | The source always points to the destination. | 228 | c) The Gain Loss Flags (12) net out. | 229 | d) Since this netted out and both instutions | 230 | are known - assume proper money flow. | 231 | e) If there are extra unexplained transactions at | 232 | the destination or a missing destination then | 233 | further investigation is required. | 234 | f) Get additional accounts and records as needed. | 235 +-----------------------------------------------------------------+ 237 4. Prototype Data 239 Below are several screens (RFC ASCII figures) that display a 240 potential solution. Each record has date and time stamp information 241 and other data. The key is to have the creator of the record as the 242 first instution (left). Then the affiliate instution (right) as the 243 handshake. Each transaction has an initiator and a receiver. If both 244 instutions create the same format record , it becomes a simple 245 crisscross reference match. 247 This a protype of record layout names: 248 Counter - Field Name 249 01 - Record Type 250 02 - Date 251 03 - Time 252 04 - AM or PM indicator 253 05 - Zone 254 06 - UTC 255 07 - UTC Offset 256 08 - Day Name 257 09 - GUID 258 10 - Record Owner 259 11 - Record Owner Account Number 260 12 - Handshake Flag 261 13 - Gain/Loss Flag 262 14 - Record Affiliate 263 15 - Record Affiliate Account Number 264 16 - Transaction Type 265 17 - Transaction Sub Type 266 18 - Teller ID / Station ID 267 19 - Amount of Transaction 268 20 - Currency Code 269 21 - Country and Currency 270 22 - DUNS 271 23 - Name 272 24 - Street/PO Box 273 25 - City 274 26 - State/Province 275 27 - Country 276 28 - ZIP/Postal Code 277 29 - Comment 278 30 - End of Record Marker (FX) 279 RFC ASCII figure A.1 Data Examples 280 +----------------------------------------------------------------+ 281 | Four (4) sets of examples over next five (5) pages. | 282 | | 283 | | 284 | | 285 | R T O | 286 | e y f | 287 | c p Z f | 288 | o e o U s | 289 | r AM n T e Day | 290 | d Date Time PM e UTC C t Name | 291 | | 292 | -01- ----02---- --03---- 04 05- ---06--- 07- ----08--- | 293 | AUKC 2019-01-31 14:45:59 PM CDT 20:45:59 +06 Thursday | 294 | AUKC 2019-02-01 04:01:00 AM CDT 10:01:00 +06 Friday | 295 | This shows the transactions netted out. | 296 | | 297 | AUKC 2019-01-22 15:53:11 PM CST 21:53:11 +06 Tuesday | 298 | AUKC 2019-01-23 05:03:11 AM CST 11:03:11 +06 Wednesday | 299 | AUKC 2019-01-25 11:03:11 AM CST 17:03:11 +06 Friday | 300 | This shows a large cash withdrawal. | 301 | | 302 | AUKC 2019-01-22 15:53:11 PM CST 21:53:11 +06 Tuesday | 303 | AUKC 2019-01-23 05:03:11 AM CST 11:03:11 +06 Wednesday | 304 | AUKC 2019-01-25 11:03:11 AM CST 17:03:11 +06 Friday | 305 | This show final transfer to an unknown bank "2222222222 | 306 | | 307 | AUKC 2019-01-22 15:53:11 PM CST 21:53:11 +06 Tuesday | 308 | AUKC 2019-01-23 05:03:11 AM CST 11:03:11 +06 Wednesday | 309 | AUKC 2019-01-25 11:03:11 AM CST 17:03:11 +06 Friday | 310 | AUKC 2019-01-25 11:53:11 AM CST 17:53:11 +06 Friday | 311 | AUKC 2019-01-25 14:03:11 PM CST 20:03:11 +06 Friday | 312 | This record shows interest , cash withdrawal and fees. | 313 | | 314 | | 315 +----------------------------------------------------------------+ 316 RFC ASCII figure A.2 317 +----------------------------------------------------------------+ 318 | | 319 | Handshake Flag | 320 | || | 321 | || | 322 | || Gain / Loss Flag | 323 | || || | 324 | Record || || | 325 | Record Owner Owner || || Affiliate | 326 | Instution Account || || Instution | 327 | GUID Number Number VV VV Number | 328 | | 329 | ------09---- ----10------ ----11----- 12 13 -----14----- | 330 | AAAAAZZZZZ 12345678 acc12345678 => -1 99997777 | 331 | AAAAAZZZZZ 99997777 acc99997777 <= +1 12345678 | 332 | | 333 | | 334 | FX1234-AAFGH 88888888 acc8888888 => -1 444444444444 | 335 | FX1234-AAFGH 444444444444 acc4444444 <= +1 88888888 | 336 | ZZZZZ99998 444444444444 acc4444444 => -1 | 337 | | 338 | | 339 | FX1234-AAFGH 88888888 acc8888888 => -1 444444444444 | 340 | FX1234-AAFGH 444444444444 acc4444444 <= +1 88888888 | 341 | MMM55555 444444444444 acc4444444 => -1 2222222222 | 342 | | 343 | | 344 | GUIDAAAA 12345678 accAAAAA => -1 88888888 | 345 | GUIDAAAA 88888888 accBBBBBB <= +1 12345678 | 346 | GUIDINTREST 88888888 accBBBBBB == +0 | 347 | GUIDCASH 88888888 accBBBBBB => -1 | 348 | GUIDPENETLY 88888888 accBBBBBB == -0 | 349 | | 350 | | 351 | | 352 +----------------------------------------------------------------+ 353 RFC ASCII figure A.3 354 +----------------------------------------------------------------+ 355 | | 356 | | 357 | Transaction Type | 358 | || C | 359 | || u | 360 | || Sub Type r | 361 | || || r | 362 | || || e C | 363 | Affiliate || || n o | 364 | Account || || Teller ID / Amount of c d | 365 | Number VV VV Station ID Transaction y e | 366 | | 367 | ----15----- 16 17 -------18------- -----19---- 20- | 368 | acc99997777 R -123,456.78 USD | 369 | acc12345678 B +123,456.78 USD | 370 | | 371 | | 372 | acc4444444 R Home Phone XMIT -123,456.99 USD | 373 | acc8888888 B +123,456.99 USD | 374 | CW T41 Terminal AAD -23,456.00 USD | 375 | | 376 | | 377 | acc4444444 R Home Phone XMIT -123,456.99 USD | 378 | acc8888888 B +123,456.99 USD | 379 | acc222222 R -23,456.00 USD | 380 | | 381 | | 382 | accBBBBBB R Home Phone XMIT -88777.66 USD | 383 | accAAAAA B +88777.66 USD | 384 | I +10.00 USD | 385 | CW -70,000.00 USD | 386 | F -20.00 USD | 387 | | 388 | | 389 | | 390 +----------------------------------------------------------------+ 391 RFC ASCII figure A.4 392 +----------------------------------------------------------------+ 393 | | 394 | | 395 | | 396 | | 397 | Mailing | 398 | Country and Currency DUNS Name Street/PO Box | 399 | | 400 | ---------21---------- ----22--- ------23--- -------24------ | 401 | United States, Dollar Big Bank 123 Long St | 402 | United States, Dollar Little Bank 123 Short St | 403 | | 404 | | 405 | United States, Dollar Big Bank 123 Some Rd | 406 | United States, Dollar Little Bank 888 Lonesome Rd | 407 | United States, Dollar Little Bank 888 Lonesome Rd | 408 | | 409 | | 410 | United States, Dollar Big Bank 123 Some Rd | 411 | United States, Dollar Little Bank 888 Lonesome Rd | 412 | United States, Dollar Little Bank 888 Lonesome Rd | 413 | | 414 | | 415 | United States, Dollar Big Bank 123 Some Rd | 416 | United States, Dollar Little Bank 888 Lonesome Rd | 417 | United States, Dollar Little Bank 888 Lonesome Rd | 418 | United States, Dollar Little Bank 888 Lonesome Rd | 419 | United States, Dollar Little Bank 888 Lonesome Rd | 420 | | 421 | | 422 | | 423 +----------------------------------------------------------------+ 424 RFC ASCII figure A.5 425 +----------------------------------------------------------------+ 426 | | 427 | | 428 | C | 429 | o M | 430 | S u a | 431 | tP n r | 432 | ar t ZIP Ek | 433 | to r Postal ne | 434 | City ev y Code Comment dr | 435 | | 436 | ----25----- 26 27- --28------ ---29----------------------- 30 | 437 | Big City WI USA 555555 None today FX | 438 | Little Town WI USA 777777 FX | 439 | | 440 | | 441 | InTown WI USA 99999-8889 None Today FX | 442 | OutTown WI USA 77777-8889 Lots of Money I'm Flush ! FX | 443 | OutTown WI USA 77777-8889 Stole This for Friday Night FX | 444 | | 445 | | 446 | InTown WI USA 99999-8889 None Today FX | 447 | OutTown WI USA 77777-8889 Lots of Money I'm Flush ! FX | 448 | OutTown WI USA 77777-8889 Stole This for Vacation FX | 449 | | 450 | | 451 | InTown WI USA 99999-8889 None FX | 452 | OutTown WI USA 77777-8889 FX | 453 | OutTown WI USA 77777-8889 Interest FX | 454 | OutTown WI USA 77777-8889 Cash FX | 455 | OutTown WI USA 77777-8889 Fee Bad Check FX | 456 | | 457 | | 458 | | 459 | | 460 +----------------------------------------------------------------+ 462 5. File Naming 464 Since there might be several years of records requested , 465 there is a need for a specific naming convention of the 466 downloaded files and the amount of data. 468 Each file will contain data for only one full year: 469 from - January 01 , or start date of account. 470 to - December 31 , or the current date of the current year , 471 - or closing date of account. 473 Each file will contain data for only one account. 475 The file name will have an extension of ".aukc". 476 The file name will be as follows: 477 YYYY - four-digit year 478 Underscore - "_" 479 Institution number - alpha/numeric 480 Underscore - "_" 481 Last five digits of account - alpha/numeric 482 Underscore - "_" 483 Last name of records requestor - alpha 485 Examples: 486 YYYY_Instution_Last5Acc_Name.aukc 488 2017_1234567_88888_fields.aukc 489 2018_1234567_88888_fields.aukc 490 2019_1234567_88888_fields.aukc 492 2017_9876543aaa_20x20_fields.aukc 493 2018_9876543aaa_20x20_fields.aukc 494 2019_9876543aaa_20x20_fields.aukc 496 The data will be in a .csv format in a flat file. 498 6. Formal Syntax 500 Field ## 501 -Desc -Rule 502 - all data is CSV format. 503 - double quotes and comma. 504 - empty fields one space character 505 - required. 506 - no double quotes (") or 507 - single quotes (') or 508 - comma's (,) allowed in the data , 509 - strip off before file creation. 511 Record Type ## 512 -Key to identify the data type 513 - 4 position constant value of 514 - capitol "AUKC" ; 515 - first four characters - first field 516 - "Audit Un-Known Cash" 518 ############## Date and Time Stamps and Day of Week 519 - Creation of the transaction. 520 - 521 - 2019-01-22 02:47:59 AM CST 522 - 08:47:59 +06 Tuesday 523 - 524 - each value is a separate field. 525 - needed if transaction 526 - crosses time zones or days. 527 - keys to sort / search records. 529 Date ## - "YYYY-MM-DD" 530 Time ## - "HH:MM:SS" - local time military format 531 AM/PM ## - "AM" or "PM" indicator 532 Zone ## - "CST" or "CDT" - local time zone code 533 UTC ## - "HH:MM:SS" - UTC time stamp 534 UTC Offset ## - "+nn" or "-nn" - UTC zone offset 535 Day Name ## - "Wednesday" - Day of Week Name 536 - Full name of local day 538 GUID ## 539 -A unique ID 540 - Probably the ACH number 541 - (ACH) Automated Clearing House 542 - Institution name , date , 543 - account , ??? 544 - this GUID is kept with the sending 545 - instutions , and is received by the 546 - receiving instutions. 547 - It is the traceable element 548 - to track the flow of money. 550 Record Owner ## 551 -What entity created the record 552 - 32 position alpha/numeric 553 - Financial Instution Number 554 - Routing Number / DUNS 555 - Unique business number ??? 557 Record Owner Account Number ## 558 -Financial Instutions Account Number 559 - 32 position alpha/numeric 561 Handshake Flag ## 562 -Overall Direction of the trans action 563 - 3 position text symbols. 564 - a leading single quote {'} 565 - "'=>" outbound or 566 - "'==" neutral - internal or 567 - "'<=" inbound. 568 - When tracing a pair of transactions 569 - the arrows should net out. 571 Gain/Loss Flag ## 572 -A global money gain/loss flag 573 - in or out or neutral 574 - 3 position signed field. 575 - a leading single quote (') 576 - plus (+) or minus (-) and 577 - zero (0) or one (1). 578 - internal record: 579 - "'+0" is interest or correction - gain. 580 - "'-0" is fee , penalty - loss. 581 - external record: 582 - "'-1" is transferred out - loss. 583 - "'+1" is transferred in - gain. 585 Record Affiliate ## 586 -What entity received/sent the record and money. 587 - 32 position alpha/numeric 588 - Financial Instution Number 589 - Routing Number / DUNS 590 - Unique business number ??? 592 Record Affiliate Account Number ## 593 -Financial Instutions Account Number 594 - 32 position alpha/numeric 596 ############## All the following data fields come from the 597 ############## record owner's data. 599 Transaction Type ## 600 -What type of transaction ? 601 - 2 position field A-Z and 0-9 602 - and space. 603 - "R " = real time 604 - "B " = overnight batch 605 - "CD" = cash deposit 606 - "CW" = cash withdrawal 607 - "KD" = check deposit 608 - "KW" = check withdrawal 609 - "PI" = phone transfer in 610 - "PO" = phone transfer out 611 - "I " = interest 612 - "F " = penalty fee 613 - more needed ???? 615 Transaction Sub Type ## 616 -Additional Flags 617 - 2 position wide open 618 - reserved for future growth 619 - A-Z & 0-9 and space 621 Teller ID / Station ID ## 622 - 20 position Identifier of 623 - instutions employee / 624 - station / terminal 626 Amount of Transaction ## 627 -Numeric Currency 628 - floating point number. 629 - signed value required 630 - plus (+) or minus (-). 631 - plus +123456.78 or 632 - minus -123456.78. 633 - with a 2 position decimal value. 635 Currency Code ## 636 - 3 position currency code. 637 - USD / BBD / etc. 639 Country and Currency ## 640 - 30 position country and 641 - domination codes: 642 - United States , Dollar 643 - Barbados , Dollar. 645 DUNS ## 646 -DUNS Number 647 - 9 position 649 -Mailing address 650 Name ## - 60 position field 651 Street/PO Box ## - 60 position field 652 City ## - 40 position field 653 State/Province ## - 12 position field 654 Country ## - 3 position field 655 ZIP/Postal Code ## - 14 position field 657 Comment ## 658 - 40 position field 659 End Of Record Marker 660 - Text Constant "FX" 662 Security Considerations 664 There are numerous security concerns. We are dealing with people's 665 accounts and records. Preferred method to transfer the data is have 666 the instutions send an email to the requester. Requester opens the 667 email , then clicks a link and an automatic download of all files is 668 started. The link should be valid for a maximum of four (4) days. 669 The files (data) on the host should be available for thirty (30) 670 days ; then destroyed. 672 IANA Considerations 674 IANA should create a new code "AUKC" to identify the record type. 676 Conclusions 678 If this standard is adopted numerous manhours (time) and expense 679 (money) could be saved. There would be a single universal tool to 680 preform consistent audits of the flow of cash (money). 681 People doing the auditing could expedite the findings. This would 682 assist law enforcement and the courts to find and resolve issues 683 rapidly. "Punish the guilty". This would stop the creation of 684 different methods and reports ; one common solution could fit all 685 future data inquires. 687 History Lesson: I spent the last year auditing two (2) niece-like 688 girl 's information: 689 for six (6) years of data - 690 of two (2) bank accounts each 691 of one (1) stock account each 692 of Federal and State Income Taxes each 693 of Social Security Accounts each 694 of Fillings with the State Court for Minors each 695 There were: 696 ( 2 girls x 6 years ) x ( 2 bank + stock + 2 tax + SS + minors ) 697 for a total of: 698 ( 12 girl-years x 7 accounts ) = 84 girl-year-account record sets. 700 It's all been a manual process to create data records and 701 manufacture keys and sub-keys. A many months long process could have 702 been finished in weeks. 704 Now , I respectively submit this RFC to create a standard record. 705 And , ask the expert computer people to assist in its creation and 706 implementation. Need help to take a complex process and make into a 707 simple user-friendly gathering , merging ; and sorting and filtering 708 operation. 710 7. References 712 None currently. 714 7.1. Normative References 716 [1] Bradner, S., "Key words for use in RFCs to Indicate 717 Requirement Levels", BCP 14, RFC 2119, March 1997. 719 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 720 Syntax Specifications: ABNF", RFC 2234, Internet Mail 721 Consortium and Demon Internet Ltd., November 1997. 723 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 724 Requirement Levels", BCP 14, RFC 2119, March 1997. 726 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 727 Syntax Specifications: ABNF", RFC 2234, Internet Mail 728 Consortium and Demon Internet Ltd., November 1997. 730 7.2. Informative References 732 [3] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP 733 and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573- 734 1583. 736 [Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in 737 TCP and Its Effect on Busy Servers", Proc. Infocom 1999 738 pp. 1573-1583. 740 8. Acknowledgments 742 None currently. 744 This document was prepared using 2-Word-v2.0.template.dot. 746 Appendix A. First Appendix 748 A.1. Header level - open for future 750 None currently. 752 A.2. Second Header - open for future 754 None currently. 756 Copyright (c) 2019 IETF Trust and the persons identified as authors 757 of the code. All rights reserved. 759 Redistribution and use in source and binary forms, with or without 760 modification, is permitted pursuant to, and subject to the license 761 terms contained in, the Simplified BSD License set forth in Section 762 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 763 (http://trustee.ietf.org/license-info). 765 Authors' Addresses 767 SCOTT FIELDS 768 RETIRED 769 4315 E MILWAUKEE ST 770 JANESVILLE, WI 53546 USA 772 Phone: 608-201-0473 773 Email: cash_fields@yahoo.com