Talked about June meeting attendance trends
REAL TIME IN REAL LIFE PROJECT SECTION 2 CALL NOTES May 6, 2015 11:00 – noon ET
I.
Review of draft diagrams
The group reviewed the revised draft diagrams and noted that the language on step 3 on slide 3 needs to be modified to clarify that the consumer Receiver would get messages through its FI or 3rd Party, and not directly from the Real Time Messaging System. The group also discussed the timing of the Sender’s FI/Third Party debiting funds, and that the FI would need to secure the funds earlier in the process. It was noted that these diagrams represent the “happy path” and information should be provided on variations / exceptions that could occur. II.
Authentication The group commented that FFIEC guidelines around authentication would need to be followed and commercially reasonable procedures used that are in accordance with current regulatory requirements.
III.
Risk / Security The group agreed that the Sender’s FI would be responsible complying with all applicable rules and regulations (such as BSA/AML/OFAC) and for monitoring transactions for fraud. The group felt real time fraud screening would need to be used by the Sender’s FI. The Receiver’s FI would also be responsible for some monitoring in order to flag suspicious activity on an account. The Real Time Messaging System should have the ability to screen for pre-determined threshold and reject transaction messages for amount greater than the threshold. In addition, sender’s FIs and senders themselves could have the ability to establish a maximum allowable value, but that value could not be higher than the system wide RTMS threshold. Data will need to be encrypted and protected while in transit and at rest. PCI-like standards could be used. Directory Services will need to be defined at a high level in terms of user impact. End users should not need to have account information for other end users. In one option, the Sender could use the Receiver-provider token (such as phone number or email address) and send the message/payment with that. The Real Time Messaging System would be able to use that token to route the message to the appropriate FI, who could then identify the Receiver from among their own customers.
Real Time in Real Life Project Team Section 2 Conference Call May 6, 2015
1
IV.
Third Parties The group discussed third parties and concluded that they would need to be sponsored by a financial institution in order to connect to the Real Time Messaging System.
V.
Next Steps
NACHA staff will post notes from this meeting on the project home page. NACHA staff will incorporate the sub-groups comments into the draft paper outline.
MEETING PARTICIPANTS Pam Kennaley – American Express Nasreen Quibria – Q Insights Leo Lipis – Lipis Advisors Les Smith – Jack Henry and Associates Eric Lim – U.S. Bank Edward Woods – Mindful Insights Dan Thomas – Mindful Insights George Throckmorton - NACHA Kathy Levin - NACHA
Real Time in Real Life Project Team Section 2 Conference Call May 6, 2015
2
I.
Review of draft diagrams
The group reviewed the revised draft diagrams and noted that the language on step 3 on slide 3 needs to be modified to clarify that the consumer Receiver would get messages through its FI or 3rd Party, and not directly from the Real Time Messaging System. The group also discussed the timing of the Sender’s FI/Third Party debiting funds, and that the FI would need to secure the funds earlier in the process. It was noted that these diagrams represent the “happy path” and information should be provided on variations / exceptions that could occur. II.
Authentication The group commented that FFIEC guidelines around authentication would need to be followed and commercially reasonable procedures used that are in accordance with current regulatory requirements.
III.
Risk / Security The group agreed that the Sender’s FI would be responsible complying with all applicable rules and regulations (such as BSA/AML/OFAC) and for monitoring transactions for fraud. The group felt real time fraud screening would need to be used by the Sender’s FI. The Receiver’s FI would also be responsible for some monitoring in order to flag suspicious activity on an account. The Real Time Messaging System should have the ability to screen for pre-determined threshold and reject transaction messages for amount greater than the threshold. In addition, sender’s FIs and senders themselves could have the ability to establish a maximum allowable value, but that value could not be higher than the system wide RTMS threshold. Data will need to be encrypted and protected while in transit and at rest. PCI-like standards could be used. Directory Services will need to be defined at a high level in terms of user impact. End users should not need to have account information for other end users. In one option, the Sender could use the Receiver-provider token (such as phone number or email address) and send the message/payment with that. The Real Time Messaging System would be able to use that token to route the message to the appropriate FI, who could then identify the Receiver from among their own customers.
Real Time in Real Life Project Team Section 2 Conference Call May 6, 2015
1
IV.
Third Parties The group discussed third parties and concluded that they would need to be sponsored by a financial institution in order to connect to the Real Time Messaging System.
V.
Next Steps
NACHA staff will post notes from this meeting on the project home page. NACHA staff will incorporate the sub-groups comments into the draft paper outline.
MEETING PARTICIPANTS Pam Kennaley – American Express Nasreen Quibria – Q Insights Leo Lipis – Lipis Advisors Les Smith – Jack Henry and Associates Eric Lim – U.S. Bank Edward Woods – Mindful Insights Dan Thomas – Mindful Insights George Throckmorton - NACHA Kathy Levin - NACHA
Real Time in Real Life Project Team Section 2 Conference Call May 6, 2015
2
