Tom let Dan know that bank to bank clearing is not controlled by X12. Concern is our bandwidth.

Size: px
Start display at page:

Download "Tom let Dan know that bank to bank clearing is not controlled by X12. Concern is our bandwidth."

Transcription

1 Full Finance 6/7/2010 Dan Kazzaz presentation on Increasing Membership in X12F Concept: New work products to benefit banking Bank desire: attract 401K business from employers Problem: payroll software vendors do not support it; requires much more work than other deductions; it locks companies into payroll vendor choices for solutions Solution: standardize payroll deductions Why would others do this? Tax entities methods are inefficient; health insurance is going to need more solutions; employers are tired of manual entry How would we do this? Use MBTG and DISA to get the word out; the work would be: TR3 for these purposes; Tie TR3 to CICA for XML <> EDI cross-reference Getting people to the table goal is to get companies to Cincinnati for October; we all work on contacting payroll vendors, tax folks, investment houses supporting 401K, large employers. Today s Payment mechanisms: Cash;ATM; person to Check Credit card Promissory notes EFT RFID (toll/ski pass) e-wallet (paypal and others) SMS (text message) How do we want to standardize some of these things? Problems Credit card fraud Merchant payment time Merchant expense Excessive support at bank side Interfaces changes Challenges applying cash Can X12 help? Merchant is cross-industry doctor, retail store, school Remittance advice is needed we cannot just move money text message payment for parking meter Non-standard approaches are not scalable Should X12 work on this? Collaborative tech alignment paypal; text messaging Standards alignment; IFX, SWIFT; X9 Economic Benefit faster velocity of money means better GDP; improve retail margins Efforts under way Retail smart phone technology; some of us are beginning a push on retail the goal is to get retailers, suppliers and banks together for the October meeting. Tom asked Dan to elaborate on smart phone technology. HSA checkbook vs. HSA credit card. What could easily be done is to initiate an ACH transaction to do the payment on the spot from the smart phone. Tom let Dan know that bank to bank clearing is not controlled by X12. Concern is our bandwidth. End of Dan s material Patti put up the most recent Acknowledgment Reference Model. Replace text box with: Data moving between banks travels in one of various clearing system formats, not ASC X12. Patti: we should ask Lisa to put the entire document up on the screen for us. Patti will write to Lisa.

2 Acknowledgment Reference Model Review with Lisa Miller 6/8/2010 This document approved by subcommittee C May 14. (Document put up in GoToWebinar by Lisa today.) Lisa needs some material from us. In the beginning of the two examples, there is an opening paragraph that goes with every example. We gave her the core material but we didn t give her an opening paragraph. The paragraph occurs at 8.5 Payment Origination Model. Validate the picture. The actions are our words from the DM. Two meetings ago we removed the unless mutually agreed upon. That change to language did not get in the ARM. We gave Lisa our OK to take that out. Lisa anticipates next trimester we will have modifications to 12.6 ready for vote. Just clarifying things that have gone in to RFI s or DM s that we ve already approved. They may have a change to as well. Lisa will send us the ARM so we can build that paragraph. * We began full Finance work with the consideration of RFI s. What segments in the 997 should be used to report an error in the ST02 when the error is related to syntax or min/max? We looked at another RFI that was about ambiguities being cited by WEDI between two different health care implementation guides (TR3 s). It appears that the response indicates there really is no ambiguity. We objected to a statement that s already in one of the TR3 s to the effect that the 997 can never be used in response to any situation covered by an IG/TR3. We formally began full F with a conversation about how the virtual trimester is going. Patti: I kind of like not losing the two days to travel time. Tom: it would be good if people could be asked to only do the virtual trimester from home so that their subcommittees have their undivided attention. Sharon asked if the plan was to go to more virtual meetings. Patti said no. Constitutions have been changed at the subcommittee level to permit one virtual meeting per year; but other subcommittees, especially N and Government that are really big, need to meet face to face. It was only a year ago that steering decided they had to do something to save companies money. Patti also said she much prefers GoToWebinar over WebEx. Tom said GoToWebinar is also better than Live Meeting. Tom: I m missing the interaction with other work groups. Patti: Agreed. I miss the interaction and being able to more effectively pull others into a meeting on short notice. Sharon: I would not like to go to all virtual. Would miss the personal interaction. Tom: You really can t mentor someone on how to get around X12 in a virtual meeting. Patti: That s right. We didn t do new member orientation this time. Tom: I d prefer the first trimester be the virtual one rather than the second, because of weather and travel in the winter. Patti: That makes total sense. Mark: I have more likely access to travel money for a meeting early in the year. Patti: I will be able to continue to get the funding. In fact the testing community at Nationwide gave her an award for sticking with X12. Lisa re-joined us after Patti & Sharon left for TAS. On the : If you can t put the copy of the control number in one of those two data elements, you have to reject at the next higher level. Lisa is OK with simply saying you must report the problem at the next higher level if you cannot report it at the level at which it was received.

3 On the : Lisa indicated there have been some modifications. Tom described our concern with the italicized statement being taken out of context. (That statement being: This 997 implementation guide can NOT be used for responding to any implementation guideline (TR3). Lisa suggested to include From X230 with a dash. Tom is OK with that. Lisa indicated the formal interpretation has been phrased more strongly: must be used. In their errata they also used stronger language. Now it says that both 999 must be used and 997 must not be used. The errata quotes that clarification. Lisa and Ginger are co-chairs at WEDI. Lisa felt it more appropriate for Ginger to submit it. The TR3s involved are actually C TR3s and not N. C & N are collaborating very closely. X12F TG1 Financial Standards Development notes 6/9/2010 John Shaffer, Chair Optional Telephone, under ElectronicLocation; under IndividualLocation; under IndividualContact; under Sender; under StandardDocumentHeaderModule, should not be there. The assembly A9_4 allows for two optional choices. The schema allows for an exclusive or where only one of address or sender ID may be used, but not both. The permitted usage should actually be none, one, or both. This issue exists for both the sender and receiver information. This would be at IndividualContactAssembly_2. The EffectiveEntryDate primitive P7_12 has a description in the EffectiveEntryDateText string of The effective entry date is the date specified by the Originator on which it intends a batch of entries to be settled. It should read instead: The effective entry date is the date [CCYYMMDD] specified by the Originator on which it intends a batch of entries to be settled. The component C29_1, AchCcdTransactionCode.Component string reads: Allows the conversion and breakdown of a numeric transaction code to human readable instructions. Provides the conversoin of the ACH Transaction Code to human readable instructions. The misspelling of conversion needs to be corrected. Language developed for Acknowledgment Reference Model, 6/9/2010 On the following page, Figure XX outlines the control and audit structures utilized throughout the transmission cycles of an interchange for the Payment Origination Model. In this example, it is important to note that this data only exists in the form of its original interchange during the first point-to-point step between originator and originating financial institution. A new interchange is created by the receiving financial institution when reporting receivables data to its customer, the payment receiver. This figure depicts an end to end process showing the various parties that process a payment transaction, including several distinct point to point events: the transmission to the originating financial institution by the original interchange sender; the processing of that interchange by the sender's originating financial institution, including the acknowledgments; the routing of the payment instruction and any related remittance information by the originating financial institution to a clearing network; the receipt of the payment instruction and any related remittance information by the receiving financial institution;

4 the transmission by which a new interchange of receivables data is ultimately made available to, and processed by, the payment receiver. the transmission of acknowledgments the payment receiver may send to the receiving financial institution. The control audit structures and the specifics of the generation, transmission, receipt, and processing described below must be mutually agreed upon by all parties involved. Full Finance 6/9/2010 Prior to the actual start of full F, Chris Miller and Rob Fox joined us with a DM, action on which is being mandated by steering committee. Chris Miller presented changes to the document about representing X12 EDI metadata in CICA. The question is what pieces of metadata, and the extra pieces that you d find in a TR3, how to combine those two to build tag names. The document provides those instructions for how to build tag names. Tom: For taking existing X12 transaction sets and turning them into XML? Chris: Yes, represent existing EDI structures in a name that could be used for XML tags. Chris and Rob indicated that from a market perspective this naming convention has been well-received. F voted to approve the changes. Patti approved the three RFI s as modified , -03 and -05. Patti provided an update on steering committee. We talked about how the GoToWebinar tool has worked. Officer s meeting followed and we discussed meeting logistics for Cincinnati. X12F TG1 Financial Standards Development notes 6/10/2010 John Shaffer, Chair This is what we want for the ACH CCD document description at D_43: An ACH entry that identifies debits and credits initiated by an Originator to effect a transfer of funds to or from the account of that organization to or from the account of another organization. Note that besides the language change at the end of the sentence, the spelling of identifies needs to be corrected. At IndividualContactAssembly_2, the two constructs under the assembly are shown in XMLSpy as being an exclusive or. We think they should be shown as both optional, although the results are what we d want. We d like to know, though, why it was done this way. And, the optional individual location attached to the contact identification should not be there. At EntityLocationAssembly_4, the two constructs under the assembly are shown in XML Spy as being an exclusive or. We think they should be shown as both optional, although the results are what we d want. We d like to know, though, why it was done this way.

5 At AchCcdOriginator.Assembly, within OriginatorAccountDetail.Block, (B31_3), in the primitive AchOriginatorRoutingAndTransitNumber (P45_31), remove the parenthetical question and answer. It should now read simply: The Routing Number is used to identify the Originator s Depository Financial Institution. At AchFinancialReceiver.Assembly, within AchReceiverPaymentReference, change the parenthetical to read: (CCD, CTX, PPD). (i.e., please replace CIE with PPD.) Full Finance Thursday June 10, 2010 Margaret Weeker, the chair of N, thanked Tom again for the document we gave to Deb Strickland (our former Payment Systems Architecture TG6 document that included material on reassociation). It was almost too much information. They d like to work with key members of F to streamline it down to something more current and a little thinner for EFT in conjunction with new HIPAA guides. They may come to Tom & Bruce for that. An update from steering committee: regarding the final status of DM It passed last night, 4 approved, 3 disapproved and 1 abstention. (This was the TR2 for TR3 s). Patti will scan & the reassociation documentation that she has. Patti showed us how to find the DMs on the X12.org site.