July 4th, 2024

Release notes: Banking.Live 2.13

AUTH-446: Addition of Acquirer Country Code to Authorization Messages (Mastercard Mandate AN 7411)

Issuers will have the acquirer country code provided in authorization messages when available. This may prevent delays in their transaction processing and provide necessary information for regulatory requirements. Issuers may need to conduct a separate lookup process in the event data element (DE) 19 (Acquiring Institution Country Code) is not present.

Impact to Clients

Currently Banking.Live uses DE43_5 to identify the merchant country. With the addition of DE19, Banking.Live will now use the following logic:

If DE19 exists then use DE19 as merchant country, else use DE43_5 for merchant country.

DEC-115: Management of Rules Engine - User Adjustable values via APIs

In the Rules Engine you can create a rule with user-adjustable values. These user-adjustable values are set up and maintained via the PayControl UI, however, you are only able to override those default values on an individual card level by inserting an entry into our database.

We will provide the functionality to set these values on a card level via API.
We are also going to provide a new API which allows you to view the user-adjustable values for a specific rule & card combination.
We will be altering the List Rules API to return the user-adjustable default values if they have been set for a rule.

Impact on Clients

Two new APIs are being provided:

/pws/pws_set_rfc_params Sets Rule Parameters For a Card
/pws/pws_list_rfc_params List Card Params For Rule

One API response has been altered:

/pws/pws/list_rule List Rules

AUTH-572 & AUTH-607: Paymentology STIP: For Internal STIP clients add a balance update feature in the FAST response

STIP-enabled clients can include balance optionally in extra balance fields in fast response for the balance update and Banking.Live will rewrite/update the balance of that account with the balance present in new balance fields. This will be an optional feature for Internal STIP-enabled clients only.

Impact on Clients

No impact on clients by default as it is an optional feature targeted for STIP enabled clients only.

For more information on how this works, you can refer to the Shadow balance fields in FAST response section of the Stand-in Processing guide.

AUTH-608: Paymentology STIP: Handle shadow balance check in handle auth PayCore for MC and VISA

Back-end function to accept value forwarded by client in FAST response and to store in respective database tables. This is part of the Paymentology STIP functionality and allows Paymentology to keep a shadow balance of external authorization clients (with STIP enabled).

Impact on Clients

No impact to clients as default.

You can read more on our STIP functionality here and this specific type of STIP balance maintenance here.

CLR-175: Paymentology STIP: Determining unthrottling of the client endpoint

This enhancement will allow the system to determine whether the client is back to responsive state and is able to respond back to FAST messages.

This forms part of the Paymentology STIP functionality.

Impact on Clients

No impact to clients as default.

You can read more on our STIP functionality here.

CLR-349: Paymentology STIP: Improvements for STIP Advice message transmission

This introduces a new dedicated job for handling STIP advice messages, which will allow the system to only transmit STIP advice messages once the client comes back up from throttling.

This forms part of the Paymentology STIP functionality

Impact on Clients

No impact to clients as default.

This is a measure put in place to make sure that STIP advice messages are not transmitted to a STIP client who is
offline.

You can read more on our STIP functionality here.

CLR-363: Paymentology STIP: Adding support for a token in the balance update file

Currently the balance synchronization process requires a balance file update that carries account number as the only field to update a balance in our system for STIP processing. But depending on the client setup, it will not always happen that clients have access to account numbers and they may require an alternate method for updating those balances. This is where the token field will come into play.

This forms part of the Paymentology STIP functionality.

Impact on Clients

No impact to clients as default.

This enhancement will allow our clients to be able to use token for updating account balances as part of Paymentology STIP.

You can read more on our STIP functionality here and specific details on the format of the bulk balance update file here.

PECR-220: New Columns for Fee Transparency and Reconciliation in the Authorizations Report

This release introduces two new optional columns to the Authorizations Report to enhance visibility into transaction costs during authorization and streamlined reconciliation processes:

billing_amount_fees: Shows program fees deducted from the available balance during authorization, providing clear visibility into transaction costs upfront (subject to change after settlement).
rid_authorization: The unique identifier for each authorization record, simplifying linking multiple authorizations to a single settlement.

Impact on Clients

No impact to clients as default.

These columns are currently optional and available upon request. If you wish to receive them in your Authorizations Report, you can raise a request via our Customer Support Platform or by contacting your Client Executive.

You can read more on our Authorozations Report here.

DEC-197: Paymentology STIP: The addition of the ability to reference if a previous transaction was enabled for STIP

Our rules engine can allow a transaction to be made available for STIP via a rule. Therefore, if the call to the client’s value store were to then fail Paymentology would stand-in.

However, we cannot currently see if we stood in for a past transaction. With this change you will now be able to check if historic transactions were STIP enabled and the call to the client’s value store failed.

Impact on Clients

No impact to clients by default.

Rules can be created that reference the historical STIP outcome value for a transaction. ie. If there have been X STIP’s in the past X hours - do not make this transaction available for STIP enablement.

This is made available via a new Feature Set which can be used in any of the rules.

If you wish to utilize this in your rules, you can raise a request via our Customer Support Platform or by contacting your Client Executive.

You can read more on our STIP functionality here.

PECA-346: Enhancements to UpdateAccountBalance API endpoint

We have made two important updates to the pws_update_balance API to improve its functionality and clarity:

Limit list to max. 25 calls: Each API call is now limited to a maximum of 25 items.
Documentation update for bill_ccy field: The description for the bill_ccy field has been updated to clarify its behavior.

Impact on Clients

These updates ensure better performance and clearer documentation, enhancing the user experience and preventing potential issues related to currency conversion and call limits.

API call limit: Each call to pws_update_balance is now limited to 25 items, improving performance and preventing overload.
Clearer documentation: The bill_ccy field documentation now specifies that if a different currency is provided, it will be converted to the account’s base currency.

Clients should be aware of the new 25-item limit per API call. Additionally, the bill_ccy field should be used with the understanding that any provided currency will be converted to the account’s base currency.

Updated description for bill_ccy field:

Bill Currency: Balance currency of account. If other currency is provided, it will be converted to the account’s base currency.

PECP-152: Add SCA counter limits for Visa and MC products

Configuring transaction limits and counters for Strong Customer Authentication on a product level as part of the revised Payment Services Directive (PSD2).

❕
Note: PSD2 is specific to the EU.

This enhancement supports our clients by allowing them to set limits and counters on transactions such as contactless and ecommerce. Transaction amounts that fall below the limit can be processed securely, however once the limit is reached, the cardholder will be required to authenticate themselves.

For example, if the cardholder performs a contactless transaction above $100, then PIN entry must be enforced to avoid fraudulent purchase.

Impact on Clients

This change is available/enabled for clients that fall under the PSD2 jurisdiction.

The change is available on the UI (PayControl) when psd2_check is set to 1 and performed by the Paymentology team.

If you fall under the jurisdiction and require this to be enabled, you can raise a request through our Customer Support Platform or by contacting your Client Executive.

PECA-325: MADA Token Inquiry API is partially implemented

We have enhanced the Mada Token Inquiry API to ensure correct routing to MADA instead of VTS. Previously, the API incorrectly called the VTS API, causing unexpected behavior and timeouts. This update includes query adjustments and a refactored implementation to align with the intended functionality.

Impact on Clients

This update ensures that the Mada Token Inquiry API correctly interacts with MADA, improving reliability and preventing errors related to incorrect API calls.

Correct API Routing: The API now correctly calls MADA for token inquiries, ensuring accurate and expected behavior.
Improved Reliability: By addressing the root cause of the issue, the API interaction with MADA is now more reliable.

PECP-205: Viewing token group rules from the Rules page

This story is concerned with adding an expander to view rule details, including the conditions and actions. Previously, users could only view, add, or edit Account Groups from the rules page, but to view Token Groups, users had to navigate to a different page entirely.

Impact on Clients

No impact to clients.

This change has been made for internal Paymentology teams. It means that our Fraud Monitoring and Support Teams can better support our clients.

Change to User Interface on PayControl (Rules Screen).

AUTH-579: Fix how Partial Reversals should be displayed in PayControl

Fixed an issue with the partial reversal amount calculation for PayControl UI where the partial reversal amount was not displaying correctly.

Impact on Clients

Before this release: the replacement amount (DE95_1 or DE95_3) was displayed in ‘Loc Amt’ and ‘Bill Amt’ on the PayControl transactions screen (PayControl/transactions).

Post this release: The reversed/released amount (DE4 – DE95_1 or DE6 – DE95_3) will be displayed in ‘Loc Amt’ and ‘Bill Amt’ on the PayControl transactions screen (/PayControl/transactions).

❕
Note: This change is ONLY applicable to PayControl and does NOT impact FAST messages, any FAST UI or reporting.

DEC-203: Skipped rules stored

Rules can be skipped if the prior rule is set to either:

stop_further_processing or
skip_if_declined

Rules that are skipped due to this are now tracked and stored.

Impact to Clients

No impact to client.

DEC-53: Paymentology STIP: Internal STIP advice should not be considered in the Rules Engine

Rules Engine should not consider Internal STIP to avoid any impact on transaction count and amount. Notifications should not be inserted in the back end of the Rules Engine for historical data.

This forms part of the Paymentology STIP functionality.

Impact on Clients

No impact to clients as default.

This is a measure to ensure the Rules Engine is not causing errors by considering internal STIP messages in limit counts.

You can read more about our STIP functionality here.

PECP-210: Update the API documentation endpoint reference in PayControl

To accommodate recent API specification updates, the API documentation endpoint in PayControl has been updated.

The API specification updates mean the mandatory fields in the API specification available on PayControl and via the Developer Portal will appear above optional fields. This is one of the final steps in the API specification update and should reflect on the API Explorer within the next 2 weeks.

Impact on Clients

No impact to clients as default.

This is a part of an update made to the API specification documentation available on PayControl and the Developer
Portal.

INT-191: Visa STIP: Network message for advice retrieval mode sign on and sign off

This feature is for Visa, to enable a STIP advice on/off through a network management message to the scheme by calling the corresponding API.

Impact on Clients

No impact to clients.

This is part of the communication compliance testing procedures for Visa STIP and Banking.Live.

PECA-353: Ensure that the language field is optional in the Enroll Card to 3DS endpoint

We have addressed an issue where the 3ds_lang field, documented as optional, was being auto-defaulted. This fix ensures the field remains truly optional, aligning with its intended functionality. If populated, it will update the language as specified; if left empty, no default value will be applied.

Impact on Clients

This update provides greater flexibility and accuracy, allowing clients to choose when to override the language setup at the APATA product level without unintentionally defaulting to a specific language.

Optional Language Field: The 3ds_lang field is now correctly treated as optional in the Create Card and Enroll Card to 3DS endpoints.
Accurate Language Handling: If the field is populated, it updates with the specified ISO 639-1 two-letter language code. If left empty, it remains empty without defaulting to any language.

Clients should ensure that the 3ds_lang field is populated only when a specific language override is desired. The endpoints affected by this update are:

AUTH-600: Send FAST passive notification for unblocked authorization (Mada clients)

Send passive FAST notification when an authorization has been unblocked.

Impact on Clients

Only applicable to Mada internal auth clients and an optional feature. Clients not using Mada already have this option. A sample of this FAST notification can be found on the Developer Portal here and you can refer to the below table for use case examples:

Given	When	Then
A pre-authorization of 100 SAR is performed successfully.	The auth unblock job triggers and the original pre-authorization was not settled.	The authorization is considered expired, and the funds 100 SAR are released and credited back to the cardholder account. A passive FAST notification is sent to the client.
A pre-authorization of 100 SAR is performed successfully.	The auth unblock job triggers and the original pre-authorization is already settled.	No action will be taken.

DEFECT-1027	Renew Card API is not updating the digital token
Defect Condition	During the card replacement process, we identified an issue where the new PAN was mistakenly sent as the old PAN in requests to MeaWallet for digital token updates. This caused Visa to reject the requests due to validation checks, while Mastercard did not perform the same validation.
Defect Fix	This fix ensures that the correct old PAN and new PAN are sent during card replacements, preventing rejections by Visa and ensuring successful updates for digital tokens. • Correct PAN Update: The correct old PAN and new PAN will now be sent to MeaWallet, ensuring that Visa accepts the requests. • Improved Accuracy: By using a new property name oldPublicToken, the implementation is clearer and prevents similar issues in the future. Clients do not need to take any action. The fix involves updating the implementation to use the oldPublicToken property correctly, ensuring that the old PAN is properly distinguished from the new PAN.

DEFECT-1027

Renew Card API is not updating the digital token

Defect Condition

During the card replacement process, we identified an issue where the new PAN was mistakenly sent as the old PAN in requests to MeaWallet for digital token updates. This caused Visa to reject the requests due to validation checks, while Mastercard did not perform the same validation.

Defect Fix

This fix ensures that the correct old PAN and new PAN are sent during card replacements, preventing rejections by Visa and ensuring successful updates for digital tokens.

• Correct PAN Update: The correct old PAN and new PAN will now be sent to MeaWallet, ensuring that Visa accepts the requests.
• Improved Accuracy: By using a new property name oldPublicToken, the implementation is clearer and prevents similar issues in the future.

Clients do not need to take any action. The fix involves updating the implementation to use the oldPublicToken property correctly, ensuring that the old PAN is properly distinguished from the new PAN.

DEFECT-1095	Card status update failing from PayControl
Defect Condition	pcjs_card_status_edit API call is failing and the client was unable to change the status of the card.
Defect Fix	Failure resolved.

DEFECT-945	While adding a limit from the Load/Unload Limit Rule Groups page on PayControl, getting an error as Model Validation Failed.
Defect Condition	Validation was removed in error.
Defect Fix	Add validation to frequency which accepts 2 characters while load unload rules.

DEFECT-1099	Card history shows requests not related to the token
Defect Condition	Where multiple tokens belong to the same account the card history for other tokens linked to the account was displayed, which should not be the case.
Defect Fix	The client will see requests for the specified token when viewing card history.

DEFECT-1077	Discrepancy in the Credit Balance Summary report
Defect Condition	Current_Outstanding_Balance displayed with 2 decimal places for Jordanian clients.
Defect Fix	Current_Outstanding_Balance displayed with 3 decimal places for Jordanian clients.

DEFECT-1047	MADA transaction incorrectly declined
Defect Condition	MADA Transaction declined with 909 due to the value being too long for type character varying (16)
Defect Fix	Fix parsing sub-element 6 for DE47 in the rule engine.

DEFECT-1066	The blocked amount was not removed while posting the settlement
Defect Condition	At the time of settlement and posting blocked amount was not released and incorrectly the amount was debited force fully from customer's account when we received the Settlement Credit Voucher for the partial amount followed by a settlement - sales draft against the original authorization amount.
Defect Fix	Add missing changes in Visa V4 matching logic.

DEFECT-576	Revert changes to add new approved reason code for MC 3DS AAV OBS case
Defect Condition	The approved transactions by Paymentology have a wrong 3DS_Check indicator of "FAIL" for 3DS due to bypassed conditions: • iav_validated_by_mastercard OR • valid_on_behalf_service_mastercard_aav_verification, skip_aav_validation_mc_generated, bypass_aav_on_merchant_risk), impacting the client's decision-making
Defect Fix	Paymentology has introduced new approved reason codes to indicate that a transaction is approved due to 3D Secure bypassed conditions. • iav_validated_by_mastercard OR • valid_on_behalf_service_mastercard_aav_verification will have reason code 240. • skip_aav_validation_mc_generated will have reason code 241. • bypass_aav_on_merchant_risk will have reason code 242. These reason codes have now been added to the Developer Portal Reason Code guide here.

DEFECT-576

Revert changes to add new approved reason code for MC 3DS AAV OBS case

Defect Condition

The approved transactions by Paymentology have a wrong 3DS_Check indicator of "FAIL" for 3DS due to bypassed conditions:

• iav_validated_by_mastercard OR
• valid_on_behalf_service_mastercard_aav_verification, skip_aav_validation_mc_generated, bypass_aav_on_merchant_risk),

impacting the client's decision-making

Defect Fix

Paymentology has introduced new approved reason codes to indicate that a transaction is approved due to 3D Secure bypassed conditions.

• iav_validated_by_mastercard OR
• valid_on_behalf_service_mastercard_aav_verification

will have reason code 240.

• skip_aav_validation_mc_generated

will have reason code 241.

• bypass_aav_on_merchant_risk

will have reason code 242.

These reason codes have now been added to the Developer Portal Reason Code guide here.

DEFECT-989	Card Holder Report showing BIN as 0
Defect Condition	For 8-digit BINs the Card Holder Report shows BIN as 0
Defect Fix	Show up to 8 digits of the BIN in that column

DEFECT-1034	Fix decimal point on performunblock3 function
Defect Condition	Transaction failed to unblock due to an exception
Defect Fix	The transaction should be successful in unblocking

DEFECT-399	Rule based on a rolling 30-day period for monthly ATM withdrawal limit incorrectly considers declined transactions
Defect Condition	Monthly limit rule triggered despite the DE39 = 05 from MC
Defect Fix	Exclude declined transactions from spend history for limit type rules.

DEFECT-1104	Client is not able to log in to PayControl
Defect Condition	Client not able to login to PayContro
Defect Fix	Hotfix deployed to enable login to PayControl.

DEFECT-1063	ASI incorrectly declined when amount in DE4 is zero or non-zero
Defect Condition	For ASI transactions with processing code 28 and amount > 0 the response in DE39 and the reason code are incorrect.
Defect Fix	Do not decline transaction only if DE4 is zero or non-zero.

DEFECT-970	Some cards are getting created without a PIN for a specific client
Defect Condition	Incorrect response for certain cards when calling v2_sc_get_pin API. NOTE: Only impacted one specific client.
Defect Fix	Ensure random pin generation is happening during card manufacturing. Token returns successfully when calling v2_sc_get_pin API..

DEFECT-1005	ATM withdrawal-reversal request is not posted for cancelled transaction
Defect Condition	FAST active message not generated for ATM withdrawal-reversal request for cancelled transactions.
Defect Fix	FAST message for ATM withdrawal-reversal request is posted for cancelled transactions by Increasing transaction processing time and queue time in the Rules Engine call parameter.

DEFECT-1044	MADA Transaction declined with 909
Defect Condition	MADA transaction declined with 909 due to DE47 data in the message.
Defect Fix	MADA DE47 parsed to Rules Engine and the transaction was approved as expected.

DEFECT-1065	Divergence in Response code for MADA transactions
Defect Condition	DE47_07 = 18 parsed incorrectly in the FAST feed.
Defect Fix	Valid notes related to DE47_07_04 are excluded, if there is no relation with ARQC fail. If the transaction fails due to reason code 140, it is indicated clearly.

DEFECT-1061	Error when parsing DE7 (txn time) for generating FAST lite JSON data
Defect Condition	DE7 (txn time) not parsed in the FAST lite feed.
Defect Fix	DE7 (txn time) correctly parsed in the FAST lite feed.

ESQA-1151	Mada Internal Ledger: Capture Transaction declined with excessive capture greater than the threshold (even though the amount is within the 10% threshold value)
Defect Condition	Capture Transaction declined with excessive capture greater than the threshold (even though the amount is within the 10% threshold value).
Defect Fix	hreshold limit logic fixed. Capture Transaction will now be approved with excessive capture greater than the threshold when the amount is within the threshold value.

PECA-354	pws_rule_list not returning all rules on shared UAT
Defect Condition	The card rule system on shared UAT is not working as expected. It does not set the limit rules and it removes the rule when changing the limit.
Defect Fix	Setting and changing limit type rules on shared UAT will now work as expected.

DEFECT-1221	Sends an approval decision to the client even when DE-3_1 = 99 (unregistered value)
Defect Condition	Unregistered value of DE-3_1 (ex : 99) is approved where it should be declined.
Defect Fix	Validate the value of DE-3_1, if it’s an unregistered one then decline. Technically no change, but since the processing logic is changed as previously described then it affects the output of the FAST request body sent to the client: • Processor_Decision_Code previously 00 now 30 • Processor_Reason_Code previously 000 now 899 • Processor_Decision_Desc previously “Approved” now "Decline - Request Field Format Error"

DEFECT-1221

Sends an approval decision to the client even when DE-3_1 = 99 (unregistered value)

Defect Condition

Unregistered value of DE-3_1 (ex : 99) is approved where it should be declined.

Defect Fix

Validate the value of DE-3_1, if it’s an unregistered one then decline. Technically no change, but since the processing logic is changed as previously described then it affects the output of the FAST request body sent to the client:
• Processor_Decision_Code previously 00 now 30
• Processor_Reason_Code previously 000 now 899
• Processor_Decision_Desc previously “Approved” now "Decline - Request Field Format Error"

DEFECT-1154	3DS e-commerce transaction rejected with incorrect code
Defect Condition	Previously, there was an issue with the breaking of DE48_71_05 and DE48_71_06 field and causing issue during OBS checks ( i.e. DE48_71.1 contains 05V and matches criteria like DE48_71.2 = V and DE48_43 leading IN ('kD', 'kC', 'kE', 'kX', 'kY', 'kZ', 'kF') ).
Defect Fix	Fix contains proper breaking of those fields and setting on_behalf_service_mastercard_aav_verification flag to TRUE (there is still option to disable this, but by default this logic will be enabled i.e. flag set to TRUE as default).

June 14th, 2024

Release notes: Banking.Live 2.12

PECA-295: Outbound API to Retrieve Tokenisation Product Configuration ID (PCID) from Clients During Provisioning

This feature enables clients with proprietary logic to identify a single card's Product Configuration ID (PCID). Paymentology will contact the client to obtain the required PCID during the provisioning process, specifically when making the CheckEligibility call.

Clients can use their own logic to determine PCIDs, resulting in more precise and personalised provisioning. This, in turn, will lead to a smoother user experience for cardholders when tokenizing their cards across multiple wallets.

Impact on Clients

❕
Integration required
Clients need to integrate this feature into their systems, if they wish to use it.

This involves setting up the outbound API and ensuring their systems can handle the request and response format specified. Enhanced User Experience: Cardholders will experience an improved and seamless process when tokenizing their cards.

Clients will need to follow the below steps during integration:

Implement the outbound API to receive token requests from Paymentology.
Handling the required parameters (token and walletId) in the request.
Returning the productConfigurationId in the response.

PECP-148: Allow refund for card statuses via PayControl

We have added a new setting on the Product Configuration page to enable clients to configure which card statuses are eligible to receive a refund on a perproduct basis. By default, refunds are always allowed for active cards. Users will be able to configure which other card statuses can receive a refund, such as stopped or voided cards.

Impact on Clients

Change to the PayControl User Interface on the Product Configuration Screen to provide clients with more flexibility in handling refund cases for their cardholders.

PECA-316: Increase Character Limit for Address Fields in Card Renewal API

We have increased the pur_addr1, pur_addr2, del_addr1, and del_addr2 fields from 50 to 100 characters in the v2_pws_card_renewal API. This update allows clients to order and renew cards with longer address fields, improving the card ordering process and resolving previous limitations

Impact on Clients

Enhanced Address Handling: pur_addr1, pur_addr2, del_addr1, and del_addr2 fields now support up to 100 characters.
Improved Card Renewal Process: Clients can renew cards without issues related to address length.

DEC-154: Inclusion of public tokens in rule alerts

We now provide the ability to display the public token in the “Send Alert“ action. This is useful for clients who wish to look up a card in their back-office system without having to do wildcard searches on the masked PAN as they previously
had to do.

Impact on Clients

This addition of the public token to the alert actions is purely visual

DEC-154: Availability of STIP Functionality for Visa and Mastercard card products

Paymentology now offers Stand-In Processing (STIP) to enhance transaction reliability during system outages. STIP allows an alternate entity to manage transactions when the primary system is down due to maintenance or technical issues. We offer STIP in two configurations: with shadow balance and without shadow balance. This ensures continuous and reliable transaction handling within financial networks. This feature is available for clients using the FAST V3 transaction feed.

Impact on Clients

Should a client wishes to leverage the STIP functionality offered by Paymentology, they may engage with their Client Executive.

PECA-283: Improvements to pws_mada_token_update Endpoint

The pws_mada_token_update endpoint now accepts card MetadataInfo as optional. If provided, it overrides the database value; if not, the database value is used. Code refactoring and bug fixes have improved reliability, and unnecessary steps have been removed. This update improves the flexibility and reliability of the pws_mada_token_update endpoint, ensuring that it handles optional fields correctly and operates more efficiently.

Impact on Clients

Enhanced Flexibility: The cardMetadataInfo field can now be optionally included in requests.
Improved Reliability: Fixes and refactoring enhance the overall reliability and maintainability of the endpoint.
Streamlined Processing: Removal of unnecessary steps and incorrect assignments ensures smoother operation

AUTH-480: Issuers Can Only Submit Partial Authorization Responses When Acquirer Support is Present

We have added support to check if the acquirer supports Partial Auth by checking Field 60.10 position 12 has a value of 3 (Estimated amount and terminal accepts partial auth responses).

Impact on Clients

No client impact.

AUTH-492: Enhancing the Mastercard Identity Check Program

Paymentology implemented enhancements to the validation and rejection logic for the On-Behalf-Service (OBS) in the Mastercard Identity Check Program.

Identify the Transactions with OBS Flag: We check the Data Element (DE) 48, subfield 71, position 1 (DE-48_71_1) for the values 05 or 06, which indicates an On-Behalf-Service (OBS) transaction.
Validate MAC Key: Use the mac_key_validation_on_behalf_service_mastercard_aav_verification flag to mark transactions that meet these criteria for improved tracking and reporting.
Reject the Transaction: The transaction is rejected if DE-48_71_2 equals F (MAC key validation fail) with
mac_key_validation_on_behalf_service_mastercard_aav_verification Improvement flag

Impact on Clients

No client impacts. The default value of mac_key_validation_on_behalf_service_mastercard_aav_verification flag is FALSE. The new validation won’t take effect and no transaction will be declined. If a client decides to enable the flag, and Mastercard has implemented the F value (currently they have not) and the transaction meets the criteria then the
transaction will be rejected.

DEFECT-866	Fix mobile phone number format so that we prevent validation errors when calls are made to Apata (3DS Provider)
Defect Condition	Apata (3DS Provider) isn’t accepting the "-" on the mobile number as they are accepting this pattern only: /^\+ct Co\d{1,14}$/
Defect Fix	Improved Data Consistency: Phone numbers will be formatted correctly, ensuring smooth integration with APATA. Seamless Integration:* This change helps maintain accurate and consistent card data between PayApi and APATA. The affected endpoints are /v2/CreateCard, /v2/BatchCreateCard, and /v2/UpdateCard.

DEFECT-866

Fix mobile phone number format so that we prevent validation errors when calls are made to Apata (3DS Provider)

Defect Condition

Apata (3DS Provider) isn’t accepting the "-" on the mobile number as they are accepting this pattern only: /^\+ct Co\d{1,14}$/

Defect Fix

Improved Data Consistency: Phone numbers will be formatted correctly, ensuring smooth integration with APATA.

*Seamless Integration:** This change helps maintain accurate and consistent card data between PayApi and APATA.
The affected endpoints are /v2/CreateCard, /v2/BatchCreateCard, and /v2/UpdateCard.

DEFECT-665	There was a bug in the token swapping mechanism during the authentication settlement matching process.
Defect Condition	There was a bug when the settlement was received on an invalid PAN and trying to match the settlement.
Defect Fix	The matching logic has been fixed for such cases where we get an invalid PAN

DEFECT-901	Error while processing MTID 0503 message--UAE National Switch
Defect Condition	Number format exception while processing MTID 0503 recon message
Defect Fix	We fixed the below to resolve the exceptions: Cast the amount fields value to double the data type Process amount with the decimal factor of currency exponent.

DEFECT-901

Error while processing MTID 0503 message--UAE National Switch

Defect Condition

Number format exception while processing MTID 0503 recon message

Defect Fix

We fixed the below to resolve the exceptions:

Cast the amount fields value to double the data type
Process amount with the decimal factor of currency exponent.

DEFECT-908	Incorrect Display of Merchant Names with Special Characters
Defect Condition	Merchant Names with special characters were not displayed correctly
Defect Fix	Fixing the encoding type of DE43 according to MC specifications

DEFECT-855	MADA eComm purchases not displaying on the Timing Tab in PayControl
Defect Condition	MADA eComm transactions having DE47Tag35 failed to appear in Timing Tab in PayControl
Defect Fix	A fix is to parse the sub-fields into proper encoding format, so the logs are captured, and stored in the database.

DEFECT-978	Error while handling FAST ACTIVE response
Defect Condition	Reception of an empty FAST response from Clients
Defect Fix	Exception handling and logging of Empty Responses from Clients

May 24th, 2024

Release notes: Banking.Live 2.11

DEC-148: Introduction of Parent Accounts

The new Parent Account scope will allow the cascading of rules to the Main children accounts. Essentially - a rule will be applied to the transaction if the rule's scope is a parent of the main account of the card the transaction belongs to.

Impact on Clients

This feature allows B2B clients more flexibility in rule application.

PECA-282: EMV Chip Profile Enablement for JETCO

This feature introduces a new endpoint, pws_update_emv_script , that allows issuers to enable a new chip profile on physical cards. By POSTing values in the fields account_number, account_type, account_restriction, and account_currency_code, issuers can stage a script to update the physical chip. The chip will be updated upon the cardholder’s successful ATM authorization. Currently, this feature supports Jetco in Hong Kong.

Impact on Clients

New Endpoint Integration: Clients who wish to utilise this feature will need to integrate into the new endpoint.
Regional Support: This feature currently supports only Jetco in Hong Kong.

PECP-162: Viewing token group rules from the Rules page

Users can view, add, or edit token group rules from the Rules page. This functionality was previously only available from the Groups page; therefore, it was added to the Rules page to make it more visible for our users. Previously, users could only view, add, or edit Account Groups from the rules page, but to view Token Groups, users had to navigate to a different page entirely.

Impact on Clients

Change to User Interface on Pay Control (Rules Screen)

AUTH-238: Support for Business Rules - E-commerce for MADA Internal Ledger

As part of our rollout of internal ledger availability for the MADA card scheme, we have implemented support for Business Rules of E-commerce transactions.

Impact on Clients

No impact on users, step towards availability of internal ledger to new/existing KSA clients as an option.

DEFECT-577	API Endpoint pws_get_card_detail returns an error for some token
Defect Condition	Failure to convert property value of del_code field from type "null" to type "int"
Defect Fix	Defect resolved by updating the data type of field in card renewal API. Also, a new query was introduced to correct such data with null del_code whenever we have null.

PECA-289	Error on pws_mada_token_inquiry when parsing MADA response
Defect Condition	During internal development testing of MADA Token Inquiry endpoint, fixes were made to the error encountered while parsing the response from MADA.
Defect Fix	The Code Fix was done for parsing MADA response was corrected.

PECA-688	QMR report by BIN version doesn't exclude VISA products
Defect Condition	There was a code bug related to the casting of values.
Defect Fix	The Code Fix was done to fix the typecast, VISA product was successfully excluded from the QMR report

DEFECT-759	DE22 not populated for manual adjustment transaction
Defect Condition	Rule engine exception for tokens that have historic transactions without DE22
Defect Fix	The authorisation processing function fixed to capture DE22

May 3rd, 2024

Release notes: Banking.Live 2.10

Visa mandate: COF and recurring transaction validation enhancements

New configurable validations have been added to validate received COF and recurring transactions. These improvements help in supporting the Visa Secure Digital Authentication Framework program for standing instruction merchant-initiated transactions. Standing instruction merchant-initiated transactions are transactions that involve standing instructions provided by the customer in the original customer-initiated transaction. They need to meet the same criteria as customer-initiated transactions to qualify for fraud dispute protection.

Client impact

By default, clients are not affected, and these transactions are processed as normal.

The introduced validation conditions to validate received COF and recurring transactions are set at client-level and/or product-level and include:

By default, COF and Recurring transaction validation will be bypassed.
Check the previously approved transaction for that PAN having Card Acceptor Identification Code DE42 value same as the current COF or Recurring transaction. If it does not exist, decline the transaction.
Check the previously approved Account Verification transaction DE25 = 51 for that PAN having Card Acceptor Identification Code DE42 value the same as the current COF or Recurring transaction. If it does not exist, decline the transaction.
Check the previously approved transaction having transaction identifier (DE62[2]) same as the current value of the Original Transaction Identifier (DE125[03].03) and the transaction should either match Merchant ID i.e. DE42 or Merchant Name i.e. DE43[1] with previous approved transaction. If it does not exist, decline the transaction.
Check the previously approved transaction Merchant Name (DE43_1) with the current transaction Merchant Name (DE43_1). If it does not exist, decline the transaction.

Condition 1 is the default. If you need to change the validation to a different condition, you can raise a request through the Customer Support Platform.

Visa mandate (0029985): CVV2 is no longer required for Visa Secure transactions in Europe

Before PSD2 SCA, the purpose of validating CVV2 was to validate the possession of the card. However, since the release and implementation of PSD2 SCA in Europe, the additional validation of CVV2 is not required.

As of April 2024, Acquirers are no longer required to provide the CVV2 in the authorization message for transactions authenticated using Visa Secure in Europe.

❕
Due to this change in requirement, Issuers must not decline a Visa Secure transaction in Europe based solely on a missing CVV2 value.

Client impact

Visa Secure transactions in Europe will not be declined based solely on a missing CVV2 value.
You can refer to the below table for use case examples for eCommerce transactions:

Approve transactions as CAVV is valid when:

Transaction is in EEA country
CAVV is valid
CVV2 is missing, invalid or valid

Approve transactions as CAVV validated by Visa when:

In EEA country
CAVV validated by Visa
CVV2 is missing, invalid or valid

Decline the transaction as CVV2 was invalid or missing when:

Not in EEA country
CAVV valid
CVV2 is missing or invalid

Mastercard mandate (AN8498):CVC2complaince requirements on CNP tokenized and authenticated transactions for issuers and merchants in Asia/Pacific region

As part of the mandate, Banking.Live will not decline an authorization request solely due to a lack of CVC2 data for authenticated transactions, including those originating with tokenized credentials.

This is because tokenized transactions are more secure because they contain additional security features such as the token, token expiry, and Digital Secure Remote Payment (DSRP) cryptogram.

Client impact

A domestic authorization will not be declined solely due to lack of CVC2 for authenticated transactions, including those originating with tokenized credentials.

You can refer to the below table for use case examples:

Given	When	Then
An eCommerce CNP domestic transaction is initiated	The transaction is authenticated and EMV 3DS is available and CVC2 is not available	Approve the transaction.
A tokenized CNP domestic transaction is initiated	CVC2 is not available	Approve the transaction.
An eCommerce CNP domestic transaction is initiated	The transaction is authenticated and EMV 3DS is available and CVC2 is available	Approve the transaction.
A tokenized CNP domestic transaction is initiated	The transaction is authenticated and EMV 3DS is available and CVC2 is available	Approve the transaction.

Mastercard mandate (AN7102): Introduction of Mastercard TLID

Mastercard is introducing a new Data Element (DE) 105 (Multi-Use Transaction Identification Data), sub element 001 (Transaction Link ID LID]) ) that is designed to carry a new Mastercard-generated identifier which will be used identically across the Authorization, Clearing and Single Message System platforms and all message specifications.

This transaction identifier generated by Mastercard is designed to help promote an improved and consistent linking of life cycle activity occurring after the original transaction and other related transactions.

Client impact

Clients using FAST are impacted in two ways:

For FAST authorization messages you can choose to receive this TLID in “DE105” in the ISO node of the FAST authorization message.
FAST authorization message Message_Type’s impacted are:
1. All: if you do wish to receive this TLID in the FAST authorization message, you can request this through the Customer Support Platform.
For FAST clearing messages you will receive this TLID in “DE105” in the ISO node of the FAST clearing message.
FAST clearing message Message_Type’s impacted are:
1. 1240 – First Presentments

Mada mandate: Support for Mada DS based authentication tags for SPG transactions

As part of our rollout for MADA SPG (Saudi Pay Gateway) mandate, we have implemented support for MADA DS based transactions.

MADA DS based 3DS cardholder-initiated transactions made using the physical card credentials will have additional tags in DE47 for authentication value verifications.

Client impact

Once certified, clients will receive these additional tags in the ISO node of the FAST message of these types of transactions.

Mada clients will receive additional communication from Paymentology with further details as part of the SPG Service – Mada implementation rollout.

Filter/Search for transactions using Digital Token or Device ID

PayControl users can now search for transactions by Digital Token or Device ID.

📓
TIP
A device may have multiple digital tokens linked to it, but a digital token can only be linked to one device

Client impact

Clients can choose to use this additional functionality at any stage.

You can do this by:

Once logged in to PayControl, navigate to the transactions screen. For example: https://uat.banking.live/paycontrol/transactions
In the Filter By dropdown menu, you will now find Digital Token and Device ID under the Advanced heading. Click on the method you wish to filter/search by.
Proceed to type in the Digital Token or Device ID you are searching for.
Click the search icon button.
The transaction screen will now populate with transactions based on your filter input.

Highlighting triggered rules in rules detail screen despite error

Rules that are triggered but not executed due to errors will still be marked as Triggered, and highlighted.

Client impact

Minor change to the Rules Detail screen on PayControl.

Now a triggered rule where an error was present will be reflected in two ways on the Rules Detail screen in PayControl:

Rule triggered: Err-Yes
The rule will be highlighted in green

You can see this screen by:

Once logged in to PayControl, navigate to the transactions screen. For example: https://uat.banking.live/paycontrol/transactions
Right click on the specific transaction and proceed to View Transaction > View Txn Details
On the Transaction Detail screen, click on the Rules Detail tab.

CLR-307	Make auto triggering of Settlement Fast feed tasks configurable
Summary	The order in which the client receives Settlement Active fast feeds for Mambu and passive feed (Iso) can be configured from job level
Impact on Clients	It’s a configurable change. The existing behaviour is set as the default one. It can overridden by changing the configuration, clients will have to request the configuration changes thru customer executive.

PECR-135	VAU Certification Support for All BINs
Summary	We've enhanced our Visa Account Updater (VAU) file submission process for multi-issuer clients to ensure full compliance with Visa's specifications. This enhancement addresses a mandatory regulatory requirement to ensure our clients customers card details are automatically updated with merchants, minimizing disruptions in recurring payments

MCCP-42	Improve Close Operational Day function performance
Summary	Introduction of multi-threading on some ofthe jobs within Close Operational Day

DEC-111	Usage of MasterCard Fraud Score Fields in Fraud Rule
Summary	Introduction of Parsing DE48 SE 75 and DE48 SE 76 so that they can be consumed by Rule Engine for Decision Making

AUTH-434	Change default error code on FAST failure
Summary	Currently, Banking.Live returns a generic response code, 05, in cases where FAST messages fail. With this improvement, we will be able to return a more accurate response code to the networks depending on the type of failure of the FAST message

DEFECT-177	Transaction list API occasionally failing
Defect Condition	Transaction search would occasionally timeout on PayControl Screen
Defect Fix	Search Querry Optimization by using index field, creation of partition on huge tables and using partitioned fields for search

DEFECT-558	Incorrect Parsing of DE63 for VISA
Defect Condition	DE63 sub-element 0 which indicates presence of other sub elements was the sub element 1 and hence the whole parsing was affected.
Defect Fix	The correct parsing implemented as per VISA specifications

DEFECT-576	MC 3DS AAV OBS Wrong indicator
Defect Condition	The approved transactions by Paymentology have a wrong "3DS_Check" indicator of "FAIL" for 3Ds due to bypassed conditions (iav_validated_by_mastercard OR valid_on_behalf_service_mastercard_aav_verification, skip_aav_validation_mc_generated, bypass_aav_on_merchant_risk), impacting the client's decision-making.
Defect Fix	Paymentology has introduced new approved reason codes to indicate that a transaction is approved due to 3D secure bypassed conditions. "iav_validated_by_mastercard" or "valid_on_behalf_service_mastercard_aav_verification" will have reason code 240, "skip_aav_validation_mc_generated" will have reason code 241, and "bypass_aav_on_merchant_risk" will have reason code 242.

AUTH-481	Apple Pay MDES Certification with MC
Defect Condition	Mastercard Rejected 0410 message due to extra fields inDe 48 SE 23, 30, 34 and 71
Defect Fix	The additional unexpected fields were removed

DEFECT-443	Mastercard DTAS Bypass IAV validation
Defect Condition	If in a given TransactionDE-48-26 = 327 andDE-48-71-61-02 = V then we would Bypass AAV validation results and approve the transactions as DTAS would have authenticated the transaction. However, some of the clients wanted such transactions to be declined.
Defect Fix	Introduction of Feature Flag to decline the transactions as per client’s request. The clients would have to request for Feature Flag to be enabled through theirCustomer Executives/ account Managers

AUTH-446: Addition of Acquirer Country Code to Authorization Messages (Mastercard Mandate AN 7411)

Impact to Clients

DEC-115: Management of Rules Engine - User Adjustable values via APIs

Impact on Clients

AUTH-572 & AUTH-607: Paymentology STIP: For Internal STIP clients add a balance update feature in the FAST response

Impact on Clients

AUTH-608: Paymentology STIP: Handle shadow balance check in handle auth PayCore for MC and VISA

Impact on Clients

CLR-175: Paymentology STIP: Determining unthrottling of the client endpoint

Impact on Clients

CLR-349: Paymentology STIP: Improvements for STIP Advice message transmission

Impact on Clients

CLR-363: Paymentology STIP: Adding support for a token in the balance update file

Impact on Clients

PECR-220: New Columns for Fee Transparency and Reconciliation in the Authorizations Report

Impact on Clients

DEC-197: Paymentology STIP: The addition of the ability to reference if a previous transaction was enabled for STIP

Impact on Clients

PECA-346: Enhancements to UpdateAccountBalance API endpoint

Impact on Clients

PECP-152: Add SCA counter limits for Visa and MC products

Note: PSD2 is specific to the EU.

Impact on Clients

PECA-325: MADA Token Inquiry API is partially implemented

Impact on Clients

PECP-205: Viewing token group rules from the Rules page

Impact on Clients

AUTH-579: Fix how Partial Reversals should be displayed in PayControl

Impact on Clients

Note: This change is ONLY applicable to PayControl and does NOT impact FAST messages, any FAST UI or reporting.

DEC-203: Skipped rules stored

Impact to Clients

DEC-53: Paymentology STIP: Internal STIP advice should not be considered in the Rules Engine

Impact on Clients

PECP-210: Update the API documentation endpoint reference in PayControl

Impact on Clients

INT-191: Visa STIP: Network message for advice retrieval mode sign on and sign off

Impact on Clients

PECA-353: Ensure that the language field is optional in the Enroll Card to 3DS endpoint

Impact on Clients

AUTH-600: Send FAST passive notification for unblocked authorization (Mada clients)

Impact on Clients

PECA-295: Outbound API to Retrieve Tokenisation Product Configuration ID (PCID) from Clients During Provisioning

Impact on Clients

Integration required

PECP-148: Allow refund for card statuses via PayControl

Impact on Clients

PECA-316: Increase Character Limit for Address Fields in Card Renewal API

Impact on Clients

DEC-154: Inclusion of public tokens in rule alerts

Impact on Clients

DEC-154: Availability of STIP Functionality for Visa and Mastercard card products

Impact on Clients

PECA-283: Improvements to pws_mada_token_update Endpoint

Impact on Clients

AUTH-480: Issuers Can Only Submit Partial Authorization Responses When Acquirer Support is Present

Impact on Clients

AUTH-492: Enhancing the Mastercard Identity Check Program

Impact on Clients

DEC-148: Introduction of Parent Accounts

Impact on Clients

PECA-282: EMV Chip Profile Enablement for JETCO

Impact on Clients

PECP-162: Viewing token group rules from the Rules page

Impact on Clients

AUTH-238: Support for Business Rules - E-commerce for MADA Internal Ledger

Impact on Clients

Visa mandate: COF and recurring transaction validation enhancements

Client impact

Visa mandate (0029985): CVV2 is no longer required for Visa Secure transactions in Europe

Due to this change in requirement, Issuers must not decline a Visa Secure transaction in Europe based solely on a missing CVV2 value.

Client impact

Mastercard mandate (AN8498):CVC2complaince requirements on CNP tokenized and authenticated transactions for issuers and merchants in Asia/Pacific region

Client impact

Mastercard mandate (AN7102): Introduction of Mastercard TLID

Client impact

Mada mandate: Support for Mada DS based authentication tags for SPG transactions

Client impact

Filter/Search for transactions using Digital Token or Device ID

TIP