This page details the items you will need to consider and decide upon when setting up your Electrum Finance process.
**Reconciliation processes**
A reconciliation process is defined as the set of rules that govern the matching and reconciliation of transaction records between a pair of entities.
Electrum Finance can be configured to implement multiple processes according to the services you are integrated with.
Note: When using Electrum Finance for a Digital Goods and Services service, and if Electrum connects you to more than one service provider for a certain product, then a separate Electrum Finance process must be in place for each service provider.
| Item | Decision/Action | Comments |
|---|---|---|
| Parties involved | Identify the downstream and upstream entities per Electrum Finance process. | |
| Data format | Decide whether you will be using mark-up/mark-off files, or transferring transaction data via event postings. | |
| File format/specification | If using the file data format, decide whether you will conform to the Electrum file specification or whether you will use your own specification. | We recommend that you conform to the Electrum file specification. See the table below for more information. |
| Automated resolutions |
| Automated resolution further simplifies reconciliation by reducing the need for manual intervention. For example, if there is a small disparity in transaction amount, the transaction may be rejected or accepted in favour of one party based on commercial agreements. |
| Expiry periods | Consider whether or not to set expiry periods for unmatched transactions – how long an unmatched transaction should remain in the system before 'expiring'. | This allows time for any late records to enter the system and be matched. |
| Business transactional life cycle |
| You might not need the entire process to be completed on the same cycle. For example, you may require that transaction matching is done daily, but settlement is done weekly. |
Extracts and File Delivery
If you are using files to provide transaction information, then you must decide on the following issues pertaining to format, frequency, and delivery of files.
(If you are providing transaction information via event postings, then you do not need to consider these issues.)
| Item | Decision | Comments |
|---|---|---|
| Specification | Decide on the file format to be used. | The Electrum file specification is preferred. If either or both of the entities choose to use their own file specifications, the input file records will first have to be translated before reconciliation can occur. |
| Location | Decide where Electrum will collect or drop files; this location is normally an SFTP server or AWS S3 bucket location. | The usual location is an integrator-specific S3 bucket. |
| Location details | Decide on paths for collection and organisation of files. |
|
| Connectivity | Decide how to connect to the file location. | |
| Security | Decide which security method you wish to use. | Electrum supports password or private key authentication. We recommend private key as it is more secure. |
| Time periods | Decide which time periods each file will cover. | These can differ based on whether it is a weekday, weekend, or public holiday. |
| File drop-off times | Decide by when a file should be dropped at the agreed location. | For example, within 2 hours after the specified time period has ended. |
| Matching fields | Specify which process fields from the input files will be used for matching transactions. | For example, rrn, date-time strings, or others. |
| Reconcilable fields | Specify which process fields from the input files will be used for reconciling matched transactions. | For example, transaction status or amount. |
| Output files | Decide which output files you need from Electrum. | Settlement files can be produced if the customer does payment orchestration via Electrum. |
| Data retention | Decide on how and for how long data must be stored and retained. | More recent data should be easily accessible, while older data may be archived. |
Notification and Alerting
You must decide on the following issues pertaining to alerting processes.
| Item | Decision | Considerations |
|---|---|---|
| Alerting for late files | Decide on a method for alerting about late files. | This is usually via email. |
| Notification template | Consider having a template for late file notifications. | Typically an email template. |
| Notification group | Decide who will be in the notification group. | Typically an email group. |
| Times | Decide at which times a late notification must be sent. | For example, if the file has not reached the agreed-on location one hour after the specified period. |
Other Considerations
- Discuss with Electrum any major differences in transaction handling between the two entities – for example, if one supports reversals and confirmations and the other does not.
- In rare cases, an integrator may require that there is a file overlap. This means that there is a final overall file at the end of a day that contains a summary of all the previous files for that day. You need to inform Electrum if this is a requirement and discuss with us how we should handle it.
- When a malformed (incorrectly formatted) file is submitted, Electrum Finance will try to load it and then either fail with recon exceptions or simply load zero transactions. If this happens in a production environment, Electrum needs to know:
- How you plan to generate the same file (but now in the correct format),
- What the filename will be (it can’t be exactly the same as the malformatted file),
- And how long it will take before the correct file is sent.