1. NACHA’s Risk Management Portal
Add presenter name here

2. NACHA’s Risk Management Portal
Registrations required by the NACHA Operating Rules
Third-Party Sender Registration (New)
Direct Access Registration (Re-attest)
Voluntary
Emergency Financial Institution Contact Database
Terminated Originator Database
All Financial Institutions should have already registered in the direct access database. This registration will not be migrated into the new risk management portal. Each FI will need to reregister.

3. NACHA’s Risk Management Portal
Each Financial Institution should register only once.
NACHA uses information from Accuity, the Routing Number (RTN) registrar, to link RTNs owned by the Financial Institution.
Each Financial Institution will select one employee to act as Administrator and register for access to the Risk Management Portal.
The Administrator has the ability to add up to four additional Users.
Administrators and Users have access to view and edit.

4. Financial Institution Registration
Do not use your NACHA website log-in credentials here. Click on “Financial Institution Registration”.
Financial institutions that originate ACH transactions will need to select “Originating Depository Financial Institution (ODFI)” and click on Register. Financial Institutions that receive ACH transactions, but do not originate ACH transactions will select “Receiving Depository Financial Institution (RDFI).”

5. Financial Institution Registration
The Primary RTN = ODFI Routing & Transit Number
The Primary RTN field cannot be changed after registration.
Primary RTN - Each Financial Institution must register once using its primary RTN, or RTN with which it originates all or most of its transactions. Once registered, additional RTNs can be assigned to Financial Institutions based on additional relationships or Risk Management Portal databases utilized by the Financial Institution. This field cannot be changed after registration.
ODFI or RDFI Name: This field will auto-populate based on the RTN selected. This field is editable.
Administrator Details: Administrators oversee management of the Risk Management Portal for their organization, and can access, add, modify, and remove users and/or contacts of the Portal. Each Financial Institution is required to have an administrator.
User Details: Users can access, add, and modify organization details and records in the Risk Management Portal databases utilized by the organization. Users are not required and can be added or modified at any time after registration.
Contact Person Details: The contact person will be contacted by NACHA in the event of questions or issues related to organization information or records in the Risk Management Portal databases utilized by the organization. An administrator or a user can also be the contact person, but does not have to be.
ODFI or RDFI Street Address: This is the street address associated with the main office of your Financial Institution.

6. Financial Institution Registration
The Administrator’s address cannot be the same address as any User.
Any User’s address cannot be the same as the Administrator’s address.
This contact can be the same as the Administrator, any User, or a separate contact.

7. Financial Institution Registration
Please double-check all addresses for accuracy before submitting the registration.
Any error in the address will render the Administrator or User unable to log in to the Risk Management Portal.
Administrator or User addresses cannot be edited the after submission.
The Administrator or User will have to be deactivated and re-entered!
Common errors – example – entered as:

8. Financial Institution Registration
Third-Party Sender Registration Database: Each Financial Institution will attest as to whether it does or does not maintain third-party sender customers. If a Financial Institution does maintain third-party sender customers, details of each customer must be provided after registration.
Direct Access Debit Registration Database: Each Financial Institution will need to re-attest as to whether it does or does not have maintain direct access debit relationships. If a Financial Institution does maintain direct access debit relationships, details of each relationship must be provided after registration.
Terminated Originator Database (TOD): Participation in the TOD is voluntary. If your Financial Institution decides to participate in the TOD, you will have to agree to the Terms of Use. The Terms of Use will only appear if you select to participate.
Emergency Financial Institution Contact Database: Participation in the Emergency Financial Institution Contact Database is voluntary.
‘No’ is default on all questions, but the Financial Institution needs to determine each status and each voluntary participation.

9. Initial login
NACHA must accept each registration – most will be instant, but some may take up to 3 business days
The Admin and Users will receive an with a welcome notice and temporary password.
All must login and change their password.
The new password should be between 10 and 50 characters and contain one capital letter, one number, and one special character.
If you do not receive the welcome , please check your spam and junk folders, and ensure internal servers are configured to white-list nacha.org.

10. Two-Factor Authentication
A One-Time Authentication (OTA) Code is generated at each login and sent via .
Type or copy and paste the OTA Code.
If you do not receive the OTA , please check your spam and junk folders, and ensure internal servers are configured to white-list nacha.org.

11. Portal Time-Out
The Risk Management Portal will log the User out after five minutes of inactivity.
You will be required to log back in and submit another OTA Code every time you are logged out.

12. Financial Institution Registration Management
This screen is helpful for audits.
View and edit FI information here.

13. Financial Institution Registration Management
The “Edit” icon (A) will let you edit any of the information submitted at registration with the exception of Primary RTN. This includes attesting to the TPS and DA registrations and voluntary TOD and FI Contact databases.
The “Deactivate” icon (B) will deactivate the Financial Institution along with all users, all registered third-party senders, all direct access relationships, and any emergency contacts associated with the Financial Institution. The remaining icons are quick navigation icons that take you directly to your Financial Institutions registered third-party sender customers, registered direct access relationships, TOD contributions, emergency contacts, or Financial Institution user management.
The “Edit” icon (A) will let you edit FI information.
The “Deactivate” icon (B) will deactivate the FI.

14. Registration Confirmation
Click on the “Registration Confirmation” button to print proof of registration. Print the registration confirmation after all Third-Party Sender Customers and Direct Access Debit Participants have been added. The confirmation will appear in a new screen, so please “allow pop-ups”.

15. Registration Confirmation
A one page summary will appear in a new window.
Use your browser’s print option to print and/or save the one-page registration confirmation.
This confirmation page is typically what an auditor will need in order to confirm your registration with NACHA.

16. Third-Party Sender Registration
Add, edit, view, and export TPS customers from the TPS tab.
Tab is only enabled for FIs that attest to having TPS customers.

17. Third-Party Sender Registration Two Choices to Upload TPSs
Manual Entry
Enter TPS customer information into a standard form.
Edit any entry (bulk or manual)
Bulk Upload
Upload or edit many TPS customers at one time.
Templates available in Excel, CSV, and XML.
Validations are performed by the portal.
Files placed into queue and processed at midnight on the date of upload.

18. TPS Registration – Manual Entry
Select “Manual Entry” from the TPS DB Management Screen.
A pop-up will appear. All fields marked with an * need to be completed.

19. TPS Registration - Manual Entry
ODFI Routing Number is the RTN used by TPS customer being registered.
Only register the TPS Company ID and TPS Name of the Third-Party Sender
The rule does not require the company ID and company name for every originator associated with the third-party sender.

20. TPS Registration – Bulk Upload
Select “Bulk Upload” from the TPS drop down menu or from the “TPS DB Management” screen.

21. TPS Registration – Bulk Upload
Select a template to add or modify current TPS customers.
Save the file.

22. TPS Registration – Bulk Upload
The Risk Management Portal will perform a basic schema validation and move the file into the file processing queue. Successful files will receive the message, “Files have been successfully placed in the file processing queue.” Error messages will alert users to files that do not pass the schema validation. All files are processed at midnight on the date of upload.
Chose the file and select “upload”.
The portal will perform schema validation and place the file into the processing queue.

23. Bulk Upload History
The Risk Management Portal completes a rule validation on each row of all imported files and can process a file in whole or in partial. Error messages will appear in the actions column letting the user know which row(s) failed and why.
Monitor submitted files in the Bulk Upload History.
Files will remain in “Pending” status until midnight on the date the file was received.

24. Export TPS Entries
Files can be exported in the bulk upload formats or the TPS table.
Bulk upload formats can be modified and uploaded using the bulk upload process.
The TPS table format includes the date registered, date modified, and modified by fields that are not part of the bulk upload formats.

25. Direct Access Debit Registration - Required
All ODFIs will need to re-attest their Direct Access Status.
NACHA Staff will contact the Financial Institution to confirm the Direct Access Debit Participant relationship and complete the registration with the Financial Institution.
Direct Access (DA) menu in the Portal is only enabled for FIs that have DA relationships.

26. Direct Access Debit Registration - Required
All Financial Institutions with one or more Direct Access Debit Participant relationships must provide quarterly data.
Direct Access Debit Participant relationships can be deactivated using the icons in the actions column.

27. Terminated Originator Database (TOD) - Voluntary
ODFIs and Third Parties that register for the Terminated Originator Database (TOD) will be able to perform part of their due diligence for KYC (“Know Your Customer”) by being able to add information on, investigate new and periodically verify Originators and Third-Party Senders.
Inclusion in the NACHA TOD, after being terminated for cause by an ODFI, does not mean an Originator or Third-Party Sender is prohibited from working with another ODFI. However, it allows educated business decisions about onboarding Originators or Third-Party Senders.
ODFIs are not prohibited from doing business with Originators listed in the TOD.
NACHA recognizes that some ODFIs may have greater risk tolerance and risk management practices for managing an Originator that other ODFIs may terminate.

28. TOD – Contribute and Manage Contributions
TOD menu in the Portal is only enabled for FIs that answered ‘yes’ to participate.
Select “TOD DB Management” from the TOD dropdown menu
To add a new TOD contribution, select “Contribute to TOD”.

29. TOD - Contribute
To contribute a new terminated originator or third-party sender, all fields marked with an * need to be completed.

30. TOD - Search
Searches can be done on the complete legal name, tax ID or doing business as name (DBA).
Only an exact match will return a result. No partial names or wildcards can be used to search TOD.
All contributed information will be displayed if an exact match is found. Multiple records indicate that originator or third-party sender has been terminated by multiple sources.

31. Emergency FI Contact Database - Voluntary
Financial institutions (FIs) face increasingly sophisticated fraud schemes, such as data breaches, business compromise, and other interrupters, e.g., distributed denial of service attacks (‘DDoS attacks’).
FIs respond by investing considerable resources in cyber protection technologies.
NACHA provides the Emergency Financial Institution Contact Database as a means to enable communication between financial institutions during an event as described above.
FIs can share pertinent contact information to mitigate the impact an event can have on day-to-day operations.
This database is designed to include contact information for multiple key FI personnel. Typically, FIs contribute operations and processing contacts; however, FIs should consider adding internal IT, security, or risk personnel as contacts.
A variety of contacts greatly increases the value of the Emergency Financial Institution Contact Database.

32. Emergency FI Contact Database - Contribute
Select “FIC DB Management” from the FI Contact menu tab to manage the emergency contacts representing your Financial Institution. Select “add new FI contact”.
FI Contact menu in the Portal is only enabled for FIs that answered ‘yes’ to participate.
Each Financial Institution must contribute at least one Primary Contact to enable searching.

33. Emergency FI Contact Database - Contribute
Each Financial Institution can have a total of 4 Primary Contacts and 4 Secondary Contacts
Note: the Administrator contact is not visible to searches.
Once your routing number appears, hit the blue + and it will show in a grey box below. The routing number has now been selected.

34. Emergency FI Contact Database - Search
The Emergency FI Contact Database can be searched by Routing Number or Financial Institution Name

35. Additional Resources NACHA www.nacha.org/riskmanagementportal
Your RPA Experts
Insert RPA contact information