>

BankValidatorUserGuide

From DARSwiki
Jump to: navigation, search

Preface

This article will be updated on a regular basis. Updates may be required in response to updates to DARS or changes to business processes or errors.

Refer to DARSWiki Conventions for information on icons and other conventions that may apply to this article.

Ensure you are familiar with the Data Protection Laws before adding data to records in DARS. Refer to DARSWiki FurtherHelp for further information and relevant links. Please think twice before printing this article. If a printed copy is necessary, ensure it is printed double-sided and always recycle old versions.

Introduction

This article serves as a reference guide to the Bank Account and Financial Institution Validation functionality of DARS.

In this article you will learn the various tasks and functions associated with validating constituent bank accounts when logging payments, both individually and from within a revenue batch, how to validate financial institution details, as well as any relevant business processes such as querying on validation data.

You will require the Central Gift Admin role in order to access and use the functionality described in this article. If you are unsure of your role and access rights to the DARS system, please contact the DARS Helpdesk (see DARSWiki FurtherHelp for contact details).

Background Information

The Bank Account and Financial Institution Validation was created by Zeidman Development for Blackbaud CRM. This application allows bank account details and financial institution information to be automatically validated via Unified Software, a specialist provider of online BACs payment, sort code and account checking services. The University of Oxford Development Office has contracted with Zeidman Development and Unified Software to integrate the automated validation services within DARS CRM.

In addition to validating constituent bank account details, this application will provide automatic updating of financial institution information held within the CRM, such as the bank name, branch and address details. New query nodes are also available to allow for reporting on validation status.


If you do not think that this article covers the information which you require, please return to the complete list of available User Guides.

Constituent Account Validation

Gift administrators are now able to validate constituent account details held for the purposes of processing pledges and recurring gifts where the payment method specified by the constituent is direct debit.

Account details are stored on the constituent record and can be accessed via the Accounts tab.

When account information is first entered and saved, the validation status displays as Needs Validation, as shown below. This shows that the account has not been validated previously or that details have changed since the last validation.

Screenshot showing Needs Validation status

The constituent account is validated by simply clicking on Validate. Results are returned immediately but by default, the validation details window is collapsed on completion and will need to be expanded again to see the result. In a future enhancement, the validation outcome will be displayed alongside the account details on the main account list.


In the following example, the account is found to be invalid because the account number and sort code combination is invalid. Note, the account can still be valid for direct debit because the sort code alone identifies that the institution accepts direct debit and the sort code is found to be valid.

Screenshot showing the summary details appearing when an account is not validated from within ‘’’Financial Accounts’’’


If details are found to be valid, the below information is displayed.

Screenshot showing the summary details appearing when an account has been validated from within ‘’’Financial Accounts’’’

ImportantInfo.jpg Note: Validation of constituent account details does not occur on the Add Payment, Add Pledge or Add Recurring Gift input screens where the Pay instalment automatically payment method by direct debit is selected and new account details are added via the ‘Add financial account’ pop-up as shown below.

In the below situation, once the entered account data is saved, the user must then navigate back to the Accounts tab on the main Constituent page and validate as described above. A future enhancement of Bank Validator may incorporate validation directly on this point of entry if there is sufficient demand.

Example screenshot demonstrating the situation in which the user is required to return to the Accounts tab to validate an account when new account data is added directly from within the Add a payment screen.

Validation from within a Revenue Batch

The application will validate constituent account information automatically from within any revenue batch containing the account field.

When manually entering new account details into the account field, the validation will occur when Save is clicked on the Add financial account pop-up. Alternatively, if the user is selecting account details already stored on the record of an existing constituent via the drop-down list, validation will occur as the user tabs away from the Account field or clicks into another area of the batch.


If the account details are found to be invalid, a small triangle will display in the top right-hand corner of the cell, as shown below.

Screenshot displaying how an invalid account is indicated within a revenue batch, with a small triangle in the corner of the Account cell.


Hovering over this cell corner will display the validation error returned by the Unified checking service, as shown below.

Screenshot showing an example error message displayed when hovering over the small triangle in the corner of the Account cell.

If the account details are valid, the field is displayed as normal. Validation will only occur on accounts that have not already been validated or where information has changed since the last validation was run. Since there is a cost associated with each validation request, this reduces duplication of service and unnecessary expense.

If the sort code does not exist, the following error 'Error: Unknown reason' will currently be displayed. In a future enhancement, this message will explicitly state that the sort code provided is invalid or not found.

Validation of the entire batch will also be initiated when clicking on the main batch Validate button, under Processes. After clicking Validate, if an account is found to be invalid, in addition to the above error, the following warning note 'Invalid account number / sortcode combination' will be displayed at the beginning of the row.


If multiple errors are found with the record when performing batch Validation, for example, a designation field is missing in addition to an invalid account/sort code combination, these errors will be listed in priority:

Screenshot showing how multiple, prioritised errors appear when validating within a Revenue batch

If the 'Potential duplicated constituent' warning message is invoked on a batch row, identification of the correct constituent must occur before validation of the incoming account details. This allows any correct information already held on the constituent record to be available for comparison and selection.

ImportantInfo.jpg Note: There is a known bug within the batch account information area. On clicking the main batch Validate button, constituent account details are written to the CRM regardless of whether they are valid or not. This issue is being worked on by Blackbaud and will be corrected in a future release. When corrected, account details will not be written to the constituent record until the batch is successfully committed.

As a reminder, when processing batches containing the Account field, the user should not click on the Lookup ID field until the batch has been validated. Clicking on the Lookup ID before validation will cause existing account details held on the constituent record to overwrite the incoming details in the un-validated batch. Furthermore, if no account details pre-exist, the incoming details are overwritten with blank data (i.e. effectively removed). This is a known design problem already being worked on by Blackbaud.

On batch commit, a record with an invalid account/sort code error will not be committed to the CRM but will be written to an Exception batch. The invalid information will need to be corrected before the record can be submitted to the CRM.

For revenue batches that are pre-populated from other processes such as BACS Direct debit/Generate Payments, Import from Excel or BBIS donation pages/web transactions, validation of the entire file will occur on initial open of the batch for edit and again when clicking on the main batch Validate button if any details have been changed.

UsefulInfo.jpg Note: Validation within a BBIS donation/web transactions batch will be replaced shortly by automatic validation at point of entry of direct debit details by the constituent directly on the donation page.

Validation through a BBIS Donation Page

When a person sets up a recurring gift through a BBIS Donation Page, such as via 'Online Giving', the payment method will always be set to direct debit. The person will then be prompted to input their bank account details.

The bank validation will be triggered once the Donate now button is clicked by the donor. Shown below are several examples of the error messages which may be generated if validation fails.

  1. When an invalid combination of a real account number and sort code has been entered by the donor, validation will fail and the error message Modulus check has failed will be returned.
  2. The error message displayed when an invalid combination of a real account numbers and sort code has been entered.

  3. When an invalid sort code (but a valid account number) has been entered by the donor, validation will fail and the error message Sort code is not allocated will be returned.
  4. The error message displayed when an invalid sort code, but valid account number has been entered.

  5. When an invalid account number (but a valid sort code) has been entered by the donor, validation will fail and the error message Account number format is incorrect will be returned.
  6. The error message displayed when an invalid account number, but valid sort code has been entered.

Financial Institution Validation

Over 2,000 financial institution records are currently held within the CRM. Although this data has been checked and cleared of duplicates, many of the available fields for a financial institution, such as branch name and address, may be incomplete or incorrect. The validator functionality will allow details to be validated and updated either ‘on-demand’ for individual institutions or in bulk via a Global Change. The DARS Support Centre will periodically run a Global Change process to perform this bulk validation on behalf of gift administrators.

In general, gift administrators should not need to add or validate new financial institutions and this permission is currently only available to a few Central University Gift Administrators. If a new institution is added, gift administrators with the correct permissions can validate financial institutions from the Constituent Financial Institutions page (Constituents > Configuration > Constituent Financial Institutions).


A bank and sort code can be entered with the minimum information as shown below.

Dialog box showing the simplicity of the information which can be entered for a newly added Financial Institution

The following points are useful to note:

  1. On saving of this financial institution, the validation status is shown as Never Validated.
  2. On clicking Validate, the validation will occur and the status is updated to Validated.
  3. The validation software also populates the branch and address fields as appropriate.
ImportantInfo.jpg Note: The Constituents Financial Institutions list within the CRM will not allow more than one entry with the same Institution name, Branch name and Sort Code.

When validating a financial institution, the Institution name or Branch name will be updated according to the information held by Unified for the submitted sort code. If an identical record already exists in the list, the following warning message 'The combination of Institution name, Branch name, and Routing Number must be unique' will display.

In this situation, the record is a duplicate and will need to be removed. The DARS Support Centre runs a datafix process periodically to identify and correct duplicated institution data so this should be a relatively rare occurrence.

Ad-hoc Queries

Within the ad-hoc query builder, two nodes are now available for reporting.

  1. Under Constituent > Financial Accounts there is now an Account Validation node which allows selection of accounts based on their validation status.
  2. Screenshot showing location of the query nodes from where querying on Bank Validation can be performed

  3. Under Financial Institutions there is now an Account Validation node which allows selection of financial institutions based on their validation status.


Please note that a PDF version of this document, with additional screenshots within it, is stored on the DARS Central website can be accessed by clicking the following link.


Return to the list if available User Guides.

Personal tools
Namespaces
  • Page
  • Discussion
  • Variants
    Actions
    Navigation
    DARS User Support
    DARS Support Centre
    Advancing Oxford
    Tools