Obtain Messaging Management Information Report – Overview of functionality

What is the Messaging Management Information Report?

The Messaging Management Information Report is an MI tool that is only available to Origo super users.  The report counts the number of Re-registration ISO Swift messages for each provider based on “From” and “To” dates entered by the user.

What is the Messaging Management Information Report used for?

The report is used for deriving service charges for providers that are signed up to Re-registration transfers on the Origo Transfer Service.   The number of Re-registration ISO Swift messages is directly attributable to the amount Origo charge each provider.

How do I find the Messaging Management Information Report?

When logged in to the Origo Transfer Service as an Origo super user the Messaging Management Information report can be found under the Administration menu.

What should I enter as inputs to the Messaging Management Information Report?

Enter the desired “from” and “to” dates (these are inclusive).  Report can be run for a specific provider or be run for all providers on the service.  For message type the latest integration version should be selected.   The report can be run in either detailed or summary mode.  Detailed mode will list all messages for each provider; whilst the summary mode will provide the total number of Re-registration ISO Swift messages for each provider.

What types of messages are there for Re-registration transfers?

The term messages is a reference to the relevant data that needs to be passed between providers to process a transfer end to end.  That data is passed in “messages”.   Origo users can search and access these messages via message monitor, this is helpful tool for investigating what data is getting passed back and forth by providers.  If logged in as an Origo super user the message monitor can be found under the administration menu.

To explain what types of messages are produced lets consider a provider that is signed up for Re-Registration transfers on the Origo Transfer Service and is sending a message to provider signed up for Re-Registration transfers on another competitor platform.

When the processing of a transfer is not Origo to Origo then platform providers such as Origo must apply strict industry standards in terms of the information, validation and format of messages that are sent or received by another external competitor platform.  

Example messages generated for Origo provider user for an outbound transfer message to another provider using a different platform

• Origo outbound message
• ISO Swift outbound message

In the above example an Origo outbound message is generated by either a robot (integrated) user or human user.  If the transfer was being processed entirely on the Origo platform then this would be suffice.   However in this example this message needs to be sent to and understood by another external competitor platform.  To enable this the Origo outbound message is converted to an ISO Swift outbound message adhering to the industry standards; this means that the receiving platform will be able to understand the message and process it i.e. update the transfer on their platform.  This effectively means that 2 messages exist for the same action on the transfer.

What messages should the Messaging Management Information Report count?

The message management information report counts messages as per below criteria:-

• Messages that have a last_update_date on or between the “From” and “To” dates entered by the user
• Outbound messages only
• ISO Swift message only i.e. not Origo messages
• Requested timestamp exists (a message at created status does not have a requested timestamp)

There is no “per message” charge where transfer is being processed Origo to Origo, this is why report does not count Origo messages.   Origo to Origo transfers are charged separately from this as part of annual service charge.

How is information displayed on the Messaging Management Information Report (Summary Type)?

It is important to note that although the report FINDS messages using last_update_date of message; this is not the date that is DISPLAYED on the report.

The date DISPLAYED in the report is creation_date of message.

In the example where the user inputs “from” as 01/07/2024 and “to” as 31/07/2024 this would return all messages with last_update_date on or between the forementioned dates.  The messages are then ordered by creation_date,  as it is creation_date displayed on report it is possible that the first message has a creation_date before or after the “from” date entered by the user.  Similarly for the last message it is possible that the creation_date may be before the “to” date entered.   It is not possible for the last message to have a creation_date greater than the “to” date entered as the last_update_date can never be before the creation_date.

Example report (“from” as 01/07/2024 and “to” as 31/07/2024) and dates explanation

Why does the report pull back by last_udpate_date rather than creation_date

The message management information report counts messages as per below criteria:

• Messages that have a last_update_date on or between the “From” and “To” dates entered by the user
• Outbound messages only
• ISO Swift message only i.e. not Origo messages
• Requested timestamp exists (a message at created status does not have a requested timestamp)

ISO Swift Message Key Facts:

• ISO Swift messages although created once by a user action i.e. (a provider creating/updating a transfer) go through the following system initiated automatic statuses created>requested>acknowledged.   
• Created Status - Message created when robot/user create/update transfer [Created_Date = Last_Update_Date]
• Requested Status - Message has been delivered to Bottomline [Last_Update_Date updated]
• Acknowledged Status  - Message has been acknowledged by Bottom line [Last_Update_Date updated]
• The default is that messages should always go E2E through these statuses i.e. almost instantaneously.  It is only if there is an error that a message could stay created/requested for any length of time.

ISO Swift Message and inclusion in count for charging (use of last-update_date) - Conclusion:

• All message statuses will be counted if last_update_date is on or between the “From” and “To” dates (this includes Created i.e. as last_update_date is same).  So if messages are successfully processed then always counted correctly by report.

ISO Swift Message and inclusion in count for charging (use of last-update_date) - Risks:

• As the report looks at last_update_date there is a risk a message could be charged for multiple times, this would only happen if there was an error with the message i.e. a message could be at requested status in one reporting period (and charged for), then it could change status to acknowledged in next charging period and be charged for again.  

Report Output (use of Creation Date) - Risks:

• There is a mismatch between the report look up date (last_update_date) and the output date (creation_date) on report.  This could be confusing for users of the report if the count for a provider contains a message that has had an error e.g. where the date shown is outwith what the user entered the from/to dates as.