Support Portal

The Usage page shows what your institution is billed for: the assessments Elucidate's screening ran for you, set against the budget agreed for the year, with the overage per quarter and a breakdown by day, message type, module, customer and user. Use it to follow consumption through the year, to check an invoice, or to see where the budget goes.

The page is available to institution administrators of screening institutions once Elucidate has set the day billing starts for your institution. Open the menu under your name in the header and click Usage. Before that day the entry is absent, and the assessment counts described at the end of this guide are not shown either.

Choosing a range

The page opens on the current year so far: from 1 January, or from the day counting started if that is later, up to today. Pick another range with the two date fields. The From field cannot go before the day counting started, the To field cannot go past today, and a range covers at most two years. A longer range is refused on the page and the figures keep showing the last range that was accepted.

All dates are UTC days. A day, a quarter and a budget year start at midnight UTC, not at your local midnight. Work done shortly after midnight in your own time zone can therefore fall on the previous day, and at the turn of a quarter or year on the previous quarter or year. The figures of a day are final once that day has ended in UTC.

What counts as an assessment

An assessment is one value checked by one screening module. The count follows the work the screening actually did, whatever its outcome, so a test message is counted like any other. In short:

• Transaction screening: one per field a module checked that had a value. A list counts once per item, so a message with two intermediary banks counts two for the watchlist check of intermediaries.
• Supplementary data: one per value checked against the watchlists, plus one per activity check for each value that was also keyword-checked.
• Customer screening: one per name or tag screened when a customer is posted or updated, and one per name or tag the daily batch checks for each customer.
• Monitoring: one per transaction a monitoring run checks.
• Watchlist search (the page's label for Manual screening searches): one per search. Browsing a list without a search term counts nothing.

Nothing is counted for work that failed before it completed, for screening that ended in error, or for adverse media lookups. A transaction sent on behalf of another institution is billed to the institution that sent it.

Every total comes with a breakdown by category and by source. The categories are External screening (watchlist, PEP and country checks, customer screening and the customer batch, watchlist searches), Activity check (the activity, incoherence, missing data and risk benchmark checks, and every monitoring module but one) and Conveyance risk, which has a category of its own. The sources name where the work came from: the transaction modules, supplementary data, customer screening, the customer batch, monitoring and watchlist search.

Budget and overage

The three tiles describe one budget year: the year your range ends in. Used since counts from the first billed day of that year, which is 1 January or the day counting started, up to the end of your range, and Remaining is what is left of the year's amount. A range that starts in an earlier year still gets its own totals and tables below, but the tiles stay with the year it ends in.

The tiles warn when the year's usage reaches 80% of the budget, and again when the budget is used up. Usage past the budget keeps counting and is billed quarterly as overage.

When the range reaches today, Used and Remaining carry to date and a notice says until when the range runs: the figures grow until that day has ended. A year for which Elucidate has entered no budget shows no tiles, only a note saying so. A range that ends before counting started shows only Counting starts on …; this range ends before it.

Overage by quarter lists every quarter your range touches. The Year's budget column repeats the budget of the quarter's year on each row: it is the amount the overage is measured against, not a quarterly allowance. A quarter's overage is the part of the year's usage, counted from the year's first billed day to the end of that quarter, that exceeds the year's budget, less the overage already shown for the earlier quarters of the same year. So the quarters of a year add up to the year's overage, and an invoice for a quarter can be read straight from its row.

A quarter that is still running is counted up to today, whatever your range's end, and its row says so: its label names the day it is counted to, as in Q4 2026, to 23 October 2026, and its Note reads Not final: counted to …, this quarter runs until …. A quarter of a year with no budget leaves the budget and overage empty and has a No budget for note.

Reading the tables

Summary gives the total number of assessments in the range, the number of transactions screened in it and the number of customers screened in it, with the breakdown by category and by source. The Figures as of line below it is the moment the figures were counted, in UTC.

• Daily: one row per day of the range, with the breakdown. Days without work show zeros.
• Transactions by type: one row per message type, with the number of transactions screened in the range, their assessments and the average per transaction. A transaction counts under its type in the range its screening completed in, and only there. Supplementary data and monitoring that follow in a later range add to the type's assessments in that later range but not to its transaction count. A type's average can therefore be high in a range where few transactions of that type were screened. Where none were, the average is left empty and the Note column says No transactions screened in this range. The Source columns show how much of a row is monitoring or supplementary data. A transaction deleted since it was screened has no type left; its assessments are listed under Deleted.
• Transactions in error: transactions whose screening request ended in error after assessments had been counted, for example when saving the decision failed. Each row gives the screening request's ID and reference, the message type, the first day in the range on which it was counted and its totals. The table is usually empty.
• Monitoring by module: one row per monitoring module, with its assessments over the whole range.
• Customers: who the assessments went to. Two kinds of row are ranked together, as the Type column says: an uploaded Customer, with its customer number, name and customer record ID, and a Party from your screened transactions, with its name and Account number. The 100 with the most assessments in the range are listed, and every other customer and party is summed into one All other customers row. The Customers and Parties columns count what a row stands for: 1 for a listed customer or party, the numbers summed for that last row. Line rows come last: the assessments of transactions that go to no customer, one row per reason, each shown only when it has assessments in the range (see the next section). The Source columns show where a row's work came from: an uploaded customer's is customer screening and the customer batch, a party's is its transactions' module checks, supplementary data and monitoring. The Customers column adds up to the summary's customer count, which counts uploaded customers only, and the table and Watchlist by user together add up to the range's total. A customer deleted since keeps its number and record ID but has no name left.
• Watchlist by user: the searches of each user, with the user's email. A user who has since been removed has Yes in the Deleted column.

A table with nothing to show in the range says None in this range. A range with no assessments at all shows No billable checks in this range in place of the tables below the summary.

Which customer a transaction is billed under

A transaction's assessments, with its supplementary data and its monitoring, go to its customer side: the originator or the beneficiary who is your institution's customer. It is worked out from the message whenever the figures are counted, so it applies to transactions screened before the Customers table listed parties too. It changes only how the Customers table splits the assessments, never the total, the budget or the overage.

Your institution's end of an MT message is the bank in the message's own header: the sender of a message you send, the receiver of one you receive. The customer side is the side whose bank is that bank. Bank codes are compared on their first eight characters, so a branch code makes no difference, and when one side's bank matches and the other side has no bank, the matching side is the customer. A payment often leaves out the bank at your end: the originator's bank of a payment you send, the beneficiary's bank of one you receive. So a side at your end that names no bank, neither by code nor by name, is taken to bank with you.

The customer side's exact name and account number make the party, as on the Customers page under Screening, with one difference:

• A transaction sent on behalf of another institution is billed to the institution that sent it, so its party is in the sender's Customers table. The Customers page lists it under the institution it was sent on behalf of.

Parties are not matched to uploaded customers, so a customer who also appears on your payments has a Customer row and a Party row, and a name spelled two ways makes two parties.

Each transaction goes to the first of these that applies:

1. Deleted transactions: the transaction was deleted since, so nothing is left to read its sides from. The Deleted row of Transactions by type holds the same assessments.
2. Customer side not identified: the transaction's screening was interrupted and did not complete, so no transaction was kept to read its sides from. The assessments counted before the interruption still count.
3. Bank-to-bank: transfers between banks (every MT2xx message, MT202 and cover payments included, and pacs.009) and messages that only pass between banks (MT199, MT499, MT599, MT799, MT999 and the MT742 reimbursement claim).
4. Trade finance (not split by customer): the header names a documentary credit or guarantee (an MT7xx message).
5. Bulk payments (not split by customer): the message carries several payments at once (MT101, MT102, MT104 and MT107), so no single customer can be named for it.
6. Not split by customer (pacs and imported messages): the message has no MT header, as with a pacs.008, a file import or an MT message sent without its header. A pacs header does not say which of its two banks is yours, so these are not split for now.
7. Bank-to-bank: neither side has a name, because both are given only as bank codes. Companies can have bank codes too, so a company's payment occasionally lands here.
8. Between own customers: both sides' banks are your bank.
9. The customer side's Party row. A customer side with neither a name nor an account number goes to Customer side not identified instead.
10. Passed on for other banks: both sides' banks are known and neither is yours, so your institution only relayed the payment.
11. Customer side not identified: neither side's bank is yours and at least one of them is missing.

Exporting a table

Each table, the summary and the overage per quarter included, can be downloaded as CSV or Excel with the buttons in its title row. The file holds the table for the range on screen with the page's columns, in the same order. Its figures are counted when you download it, so for a range that reaches today, or a quarter still running, it can hold checks counted since the page was loaded. Its column headings use the page's words, with the group in front of a category or source column (Category External Screening), though capitals and punctuation can differ. The file's name says which table it is. The summary is the exception: its file lists one figure per row and also carries the budget tiles and the overage per quarter. A table with no rows has no download buttons.

Assessments on a transaction, customer or party page

A transaction's detail page and a customer's record page show an Assessments line: how many assessments that transaction or customer has been counted for since counting started, over all ranges. A transaction's figure includes its supplementary data and its monitoring. A customer's figure includes the batch.

A party's page, the one marked From transactions, shows Assessments as your customer: the assessments of the transactions on which this party is your customer side, over all ranges, except those a line takes first (see Which customer a transaction is billed under). The page lists the party's transactions on either side, so the figure can look low next to that list:

• A transaction on which the party is the other bank's customer is billed under your customer on that transaction, or on one of the lines, not under this party.
• A transaction on which the party is your customer still goes to a line when one comes before the Party row in the list above: a payment between two of your customers, a trade finance, bulk payment or bank-to-bank message, or a pacs or imported message. An institution whose transactions all come as pacs or imported messages sees 0 on every party's page.
• A transaction another institution sent on your behalf is billed to that institution, so it is in the list but not in the figure.

What counts as the party depends on how the page was opened:

• From the Customers page under Screening, the party is its name and account number together, so the figure is the one its Party row in the Customers table would show over all ranges.
• From the party link of a monitoring alert, the party is the account only, so the figure covers every transaction on which that account is your customer side, under any name, as the list on the page does.

0 means the record exists but nothing has been counted for it since counting started, for example a transaction screened before that day with no monitoring since. A party is not a stored record, so its figure is 0 whenever nothing has been billed under it. Not available is not a count. It comes with its reason:

• Billed to the institution that sent it: the transaction was sent to your institution by another one, so it counts towards the sender's usage.
• Several transactions share this reference: more than one transaction carries this reference, so no single figure can be given.
• Cannot be looked up: the reference has a form the lookup cannot carry, such as one containing a slash.
• Several customers share this number: more than one customer record carries this number, so no single figure can be given.
• Customer no longer on file: the customer record has been deleted since the page was opened.
• Counting has not started: since you loaded the app, the day counting starts for your institution has been moved to a later day or removed. After a reload the line is hidden until counting starts.

When figures are unavailable

The figures are counted by the screening service at the moment you open the page. When it cannot answer, the page shows one message in red instead of any figure, an export reports the failure instead of producing a file, and the assessment lines show the message in place of a count. Nothing is lost: open the page again later.