Transaction Limits and Limits Engine

An authorized user can set the transaction limits (max transaction, daily, and weekly limits) at a user level for every monetary type of transaction. Based on these limits, a transaction can either be executed, be sent for approval, or be denied. The transaction limit is set on the basis of the base currency. All transactions are converted into the base currency and validates against the transaction limit.

In the following table, let us assume A and B are two different currencies.

This section explains how the transaction limits (max transaction, daily, and weekly limits) are structured at the company, role, feature, and user levels, and how the transaction limits are processed at the user level that has monetary type of actions. This section also explains the transaction limits engine and how it is used to handle the transactions in the application.

• A Financial Institution (FI) can,
  • Set periodic transaction limits at company, role, and action levels for all transaction types.
• An FI and authorized user can,
  • Set three types of limits for transactions at pre-approved level (0-$500 transactions do not require approval), a range of approval threshold, and auto denied amounts (anything over an amount is denied). These are applicable at user, account, and feature levels.
  • Set time-based transaction limits (Daily and Weekly).
  • Follow default handling for accounts that do not have any approval rules set.

Multi entity support

Multi Entity Support: Customers can view the dashboard, perform transfers, or view any request summary and submit requests against the entity associated with the customer during login. The feature is enhanced with Experience APIs to retrieve and post based on the Entity ID of the signed-in user.

• The Entity ID selected by the signed-in user flows through the application through the respective Experience API.
• For all fetch (GET) API calls, the system retrieves the results based on the Entity ID of the signed-in user.
• For all add/update/delete calls, the system passes and posts requests against the Entity ID of the signed-in user.

The feature supports the following modules:

Authentication	Dashboard	Account Overview
Credit Card overview	Cheque Management	Card Management
Statements	Dispute Transactions	Service Requests
PFM	Savings Pot	Account Settings
Sign In Settings	Profile Settings	Consent Management
Unified Transfers	Manage Transfers	Manage Beneficiaries
Bulk Payments	Bill Payments	Foreign Exchange
Portfolio Management	WealthOrder	Approval Matrix

The following topics are covered in this section:

• Structured transaction limits
  • Action level limits
  • Role level limits
  • Company level limits
  • User level limits
  • Deducing user permissions at user level
  • Deducing transaction limits at user level
• Processing transaction limits
  • User level daily limits
  • User level weekly limits
  • User level per transaction limits
  • Default user limits at limit group level
• Processing a transfer (steps 1 - 4)
  • Failure of a single pre-approval condition
  • Failure of more than one pre-approval condition (two/three)
• Transaction limits engine
  • Integrating Temenos Digital applications with limits engine
  • Getting the exhausted limit per day and week
  • Limits Engine API

Structured Transaction Limits

This section explains how the transaction limits are structured at the company, role, feature, and user levels.

Action Level Limits

• For all monetary features the following limits are supported for creating a transaction:
  • Max Transaction Limit: The limit set by the FI for the unit value of a transfer for a specific feature / service over online banking channel. Role, Company, and User level limits would be restricted by be max transaction limit.
  • Max Daily Limit: The limit set by the FI for the sum of values of a transfer in a day for a specific feature / service over online banking channel.
  • Max Weekly Limit: The limit set by the FI for the sum of values of a transfer in a week for a specific feature / service over online banking channel.
  • Min Transaction Value: The minimum transaction value set by the FI for a specific feature / service over online banking channel.

Role Level Limits

• For every feature in the role, if there is a monetary type of action (now supported only for creation of transactions), the following limits are set:
  • Max Transaction Limit: The maximum unit value of transaction (for a specific feature) that can be created by an online banking user who has been assigned this role.
  • Max Daily Limit: The maximum sum of value of transactions on a day (for a specific feature) that can be created by an online banking user who has been assigned this role.
  • Max Weekly Limit: The maximum sum of value of transactions in a week (for a specific feature) that can be created by an online banking user who has been assigned this role.
• These limits are less than the Action Level limits that are set by the financial institution (FI).

Company or Business Level Limits

• All the FI level controls on transaction limits can be set for internet banking user with combined access to both business and retails accounts.
  • Retail accounts
    • One or more roles having limits set for the same action - most restrictive rule is used.
    • External Permissions applied outside of the roles - Action level limits is used.
  • Business accounts
    • Roles having limits set for the same action and company limit on the same feature - most restrictive rule is used to find the max transaction limit.
    • Transaction limit restrictions added on top of the above derived set (via limit set for auto-denial of transactions) at per account and feature level.
• For every feature that has been given access, if there is a monetary type of action (supported only for the creation of transactions), the following limits are set:
  • Max Transaction Limit: The maximum unit value of transaction (for a specific feature) that can be created by any online banking user associated with the company.
  • Max Daily Limit: The maximum sum of value of transactions on a day (for a specific feature) that can be created by an online banking user associated with the company.
  • Max Weekly Limit: The maximum sum of value of transactions in a week (for a specific feature) that can be created by an online banking user associated with the company.

Deducing User Permissions (Features & Actions) at User Level

A user by default has access to only those features and actions that are:

Retail Customer

• Added to at least one of his / her role.
• Added for the user outside of the roles assigned.

Business User

• Added to his / her role AND available to the company that the user is associated with.
• These permissions can be reduced further at the user level.

Deducing Transaction Limits at User Level

Retail Customer

• If the user has access to an action through only one role, the Max Transaction Limit, Max Daily Limit, Max Weekly Limits from the Role would be the highest permitted limit for the user.
• If the user has access to an action through more than one role, the Most Restrictive rule would apply (the smallest value of the limits across all the roles would apply).
• If the user has access to an action not through a role but through externally added permission, the Max Transaction Limit, Max Daily Limit, Max Weekly Limits from the action level would be the highest permitted limit for the user.
• If the user has access to an action through a role and through an externally added permission, the Most Restrictive rule would apply - the smallest value of the limits across all the roles and the externally added permission (action level limits) would apply.

Business User

• If the user has access to an action
  • The Most Restrictive rule will apply between the role level and the Company level limits.
  • At the user level the limits may be controlled further.

Further Restrictions on User Level Limits

Retail Customer

This will be the same as the deduced transaction limits.

Business User

The user limits are set as follows for every account and every feature.

Per Transaction Limits

• Pre-approved Limit
  • Less than or equal to the deduced maximum transaction limit. The pre-approval limit can range between 0 (which means that all transactions submitted by the user for the specific feature and account will require an approval) and cannot exceed the maximum transaction limit that is restricted at the user’s role level or restricted by the bank at the company level.
  • Default value is 0. This means that all the transactions submitted by the user for the specific feature and account will require an approval.
• Auto-denied
  • This is by default same as the deduced maximum transaction limit.
  • Reduced at the user level. This means that an authorized user can choose to automatically prevent any transaction above a certain value from being created by a user. By default, there is no restriction, and the user can transfer the maximum amount allowed to self by the role assigned to the user and the limits set for the company to which the user belongs.

Daily Limits

• Pre-approved Limit
  • Less than or equal to the deduced maximum transaction limit.
  • Default value is 0
• Auto-denied
  • This is by default same as the deduced maximum transaction limit
  • Reduced at the user level

Weekly Limits

• Pre-approved Limit
  • Must be less than or equal to the deduced maximum transaction limit.
  • Default value is 0.
• Auto-denied
  • This is by default same as the deduced maximum transaction limit.
  • Reduced at the user level.

Processing Transaction Limits

This section explains how the transaction limits are processed at the user level, and the various conditions while processing a transfer.

User Level Daily Limits

For each account and each feature, a user has a deduced daily limit that is the maximum daily limit allowed to the user for the account and feature. The deduced daily limit comes from the minimum of the daily limit allowed to the customer ID and the role that the user is assigned.

Example:

D3 = Minimum of (D1, D2) → By default

D4 = Assigned to the user

For each Customer ID and each Limit Group a user has a deduced daily limit that is the maximum daily limit allowed to the user for the Customer ID and Limit Group. The default value comes from default user limits at limit group level. But this value can be changed though it cannot exceed the default calculated value.

Assessing whether a transaction meets the Daily Transaction Limit

For a transaction to meet the allowed daily transaction limit the following three conditions should be met. Say for instance that a transaction of value X is being made on Account 1 by User 1 using a action like Bill Pay → Create (Action 1). Say also, that Account 1 belongs to Customer ID #1 and Action 1 is classified as Limit Group 1. Also, we can say that this particular user 1 has been assigned a role “Role1” on Customer 1.

Condition C1: Customer’s Daily Limit (within the contract)

Sum of all transaction (Action 1 across all accounts associated with the Customer #1) + X <= D1

Condition C2: Role’s Daily Limit

Sum of all transaction (User 1, Action 1 across all accounts of Customer 1 ) + X <= D2

Condition C3: User’s Daily Limit - Account Level

Sum of all transaction (User 1, Account 1, Action 1) + X <= D3

Condition C4: User’s Daily Limit - Limit Group Level

Sum of all transaction (User 1, Customer1, all Actions belonging to Limit Group 1) + X <= D4

All the above conditions must be met for a transaction to qualify as meeting the daily transaction limit.

User Level Weekly Limits

For each account and each feature, a user has a deduced weekly limit that is the maximum weekly limit allowed to the user for the account and feature. The deduced weekly limit comes from the minimum of the weekly limit allowed to the customer ID and the role that the user is assigned.

Example:

W3 = Minimum of (W1, W2) → By default

D4 = Assigned to the user

For each Customer ID and each Limit Group a user has a deduced weekly limit that is the maximum weekly limit allowed to the user for the Customer ID and Limit Group. The default value comes from default user limits at limit group level. But this value can be changed though it cannot exceed the default calculated value.

Assessing whether a transaction meets the Weekly Transaction Limit

For a transaction to meet the allowed weekly transaction limit the following three conditions should be met. Take for instance that a transaction of value X is being made on Account 1 by User 1 using a action like Bill Pay → Create (Action 1). Also, that Account 1 belongs to Customer ID #1 and Action 1 is classified as Limit Group 1. Also, we can say that this specific user 1 has been assigned a role "Role1" on Customer 1.

Condition C5: Customer’s Weekly Limit (within the contract)

Sum of all transaction (Action 1 across all accounts associated with the Customer #1) + X <= D1

Condition C6: Role’s Weekly Limit

Sum of all transaction (User 1, Action 1 across all accounts of Customer 1 ) + X <= D2

Condition C7: User’s Weekly Limit - Account Level

Sum of all transaction (User 1, Account 1, Action 1) + X <= D3

Condition C8: User’s Weekly Limit - Limit Group Level

Sum of all transaction (User 1, Customer1, all Actions belonging to Limit Group 1) + X <= D4

All the above conditions must be met for a transaction to qualify as meeting the Weekly transaction limit.

User Level Per Transaction Limits

For each account and each feature, a user has a deduced max per transaction limit that is the maximum limit allowed to the user for the account and action. the deduced per transaction limit comes from the minimum of the per transaction limit allowed to the customer ID and the role that the user is assigned.

Example:

T3 = Minimum of (T1, T2) → By default

T4 = Assigned to the user

For each Customer ID and each Limit Group a user has a deduced per transaction limit that is the maximum limit allowed to the user for the Customer ID and Limit Group. The default value comes from default user limits at limit group level. But this value can be changed though it cannot exceed the default calculated value.

Assessing whether a transaction meets the Per Transaction Limit

For a transaction to meet the allowed transaction limit the following three conditions should be met. Say for instance that a transaction of value X is being made on Account 1 by User 1 using a action like Bill Pay → Create (Action 1). Say also, that Account 1 belongs to Customer ID #1 and Action 1 is classified as Limit Group 1. Also, we can say that this specific user 1 has been assigned a role "Role1" on Customer 1.

Condition C9: User’s Per Transaction Limit - Account Level

X <= T3

Condition C10: User’s Per Transaction Limit - Limit Group Level

X <= T4

All the above conditions must be met for a transaction to qualify as meeting the Weekly transaction limit.

Default User Limits at Limit Group Level

Every user will have a limit which is maintained at an overall user level for each customer ID and is restricted by the account level limits but independently managed, maintained, and checked. This will be in addition to the account level limits of the user.

The application automatically derives the default limits that the new user will have at account and feature levels, and at a per limit group level per customer ID to which the user has access. The application also ensures that the limits are subject to restrictions that FI has imposed on the customer ID and the role that has been assigned to the user for the customer ID.

Account level Limits of a user

Limit Group level limits of a user

For all limit groups, the following logic is used to derive the default limits:

For a Customer #A and Limit Group LG #1

• Per Transaction Limit
  • This will be Max of (Max Per Transaction limits → for all actions classified as LG #1 across all the accounts under Customer #A that the user has access to)
• Daily Transaction Limit
  • This will be Sum of (Max Daily Limit → for all actions classified as LG #1 across all the accounts under Customer #A that the user has access to)
• Weekly Transaction Limit
  • This will be Sum of (Max Weekly Limit → for all actions classified as LG #1 across all the accounts under Customer #A that the user has access to)

Processing a Transfer

Processing a Transfer: Step 1 - Meeting all the transaction limits

A transfer of Value X being made must meet,

• Per Transaction Limit (two conditions as described in the section above).
• Daily transaction limit (four conditions as described in the section above).
• Weekly transaction limit (four conditions as described in the section above).

If any of these conditions are not satisfied, the transfer is not executed.

Processing a Transfer: Step 2 - Auto denying a transaction

Even if a transfer of Value X has made it through Step 1, it is possible that the transaction might be auto denied if the user’s Auto Denied limits is crossed.

• This is determined as,
  • Condition AD1: Auto Denial based on Per Transaction Limit. This condition is true If X falls within the Auto Denial range for (User 1, Account 1, Action 1) for per transaction limit.
  • Condition AD2: Auto Denial based on Daily Limit. This condition is true If X falls within the Auto Denial range for (User 1, Account 1, Action 1) for per daily limit.
  • Condition AD3: Auto Denial based on Weekly Limit. This condition is true If X falls within the Auto Denial range for (User 1, Account 1, Action 1) for weekly limit.
• If any of these above conditions are true, the transaction is auto denied.

Processing a Transfer: Step 3 - Pre-approving a transaction

• If a transfer of Value X has made it through Step 1 and 2, it is checked if the transaction can be executed immediately or needs to go through the approval process.
• Determining if a transaction can be pre-approved depends on the following conditions:
  • Condition PA1: Pre-Approval based on Per Transaction Limit. This condition is true If X falls within the Pre-Approval range for (User 1, Account 1, Action 1) for per transaction limit.
  • Condition PA2: Pre-Approval based on Daily Limit. This condition is true If X falls within the Pre-Approval range for (User 1, Account 1, Action 1) for per daily limit.
  • Condition PA3: Pre-Approval based on Weekly Limit. This condition is true If X falls within the Pre-Approval range for (User 1, Account 1, Action 1) for weekly limit.
• A transfer must satisfy all of the above conditions for it to be auto-approved. If any of the conditions fail, the transfer goes through the approval process.

Processing a Transfer: Step 4 - Processing approval for a transaction

• A transfer of value X must fail one or more of the conditions for pre-approval to qualify to get into the approval process.
• These conditions are:
  • Condition PA1: Pre-Approval based on Per Transaction Limit.
  • Condition PA2: Pre-Approval based on Daily Limit.
  • Condition PA3: Pre-Approval based on Weekly Limit.
• Consider the following cases:
  • Failure of a single pre-approval condition.
  • Failure of more than one pre-approval condition (two/three).

Failure of a single pre-approval condition

When any one the pre-approve conditions have failed for transactions made on accounts of a customer, the transaction is processed according to the rules that have been set up in the customer’s Approval Matrix.

No approval rules set up

The company’s approval matrix is looked up based on the following parameters:

• Account on which the current transfer has been initiated.
• Type of Limit where the failure occurred based on which, the condition failed.
  • Per Transaction Limit
  • Daily Limit
  • Weekly Limit
• Feature using which the current transfer has been initiated.

There can be three conditions under which Approval Rules will not be available:

• Approval Matrix turned off turned-off entirely for a customer. The transactions will be executed straight through without the need for any approvals.
• "No Approvals required" selected as the rule for the particular value range. The transactions will be executed straight through without the need for any approvals.
• No rules have been set up at all for ranges in the value of the transaction. The transfer will fail because it needed to go through an approval, but the organization has not specified the Signatory Groups. Therefore, the transfer cannot be processed.

Approval rules set up

The company’s approval matrix is looked up based on the following parameters:

• Account on which the current transfer has been initiated.
• Type of Limit where the failure occurred based on which, the condition failed.
  • Per Transaction Limit
  • Daily Limit
  • Weekly Limit
• Feature using which the current transfer has been initiated.

For the Approval Rule to be valid, the following two conditions must be satisfied:

• Approval Matrix should not be turned-off for the customer.
• There must be a rule that has been set up for the value of the transaction (valid rule must be present for the condition on which the pre-approve for the transaction has failed).

The list of the Signatory Groups and the Approval Rule must be used to send out approval requests to all the relevant users basis the Signatory Groups (Approval Requests are sent out to all valid users of the Signatory Groups that are listed in the Approval Rule).

The transfer will stay in the Pending Approval Status until the required number of approvals based on the approval rule has been received.

Failure of more than one pre-approval condition (two/three)

When more than one pre-approve condition has failed for transactions made on accounts of a customer, the transaction is processed according to the rules that have been set up in the customer’s Approval Matrix for each one of those failed conditions.

No approval rule set up

The company’s approval matrix is looked up based on the following parameters:

• Account on which the current transfer has been initiated.
• Type of Limits where the failure occurred based on which, the conditions failed. In this case, two or more conditions would have failed.
  • Per Transaction Limit
  • Daily Limit
  • Weekly Limit
• Feature using which the current transfer has been initiated.

There can be three conditions under which Approval Rules will not be available (for one or more conditions):

• Approval Matrix turned off turned-off entirely for a customer. The transactions will be executed straight through without the need for any approvals. If there is one condition for which approval rules are present but another condition for which there are no rules, then the approvals are sought only for the condition where there are rules available.
• "No Approvals required" selected as the rule for the value range. The transactions will be executed straight through without the need for any approvals. If there is one condition for which approval rules are present but another condition for which there are no rules, then the approvals are sought only for the condition where there are rules available.
• No rules have been set up at all for ranges in the value of the transaction. Even on a single condition the transfer will fail because it must go through an approval, but the organization has not specified the Signatory Groups or approvers. Therefore, the transfer cannot be processed. Note that this is driven by the configuration on whether the banks would like straight through processing or blocking the transfers as default.

Approval rules set up

The company’s approval matrix is looked up based on the following parameters:

• Account on which the current transfer has been initiated.
• Type of Limit where the failure occurred based on which, the condition failed.
  • Per Transaction Limit
  • Daily Limit
  • Weekly Limit
• Feature using which the current transfer has been initiated.

For the Approval Rule to be valid, the following two conditions must be satisfied:

• Approval Matrix should not be turned-off for the customer.
• There must be a rule that has been set up for the value of the transaction (valid rule must be present for the condition on which the pre-approve for the transaction has failed).

Approval Requests

• The list of the Signatory Groups and the Approval Rule must be used to send out approval requests to all the relevant users basis the Signatory Groups (Approval Requests are sent out to all valid users of the Signatory Groups that are listed in the Approval Group).
• To be sent to the unified list of all approvers from different Signatory Groups.
• Note that if the same Group appears for multiple failed conditions, then the request is sent only once to all the users in the Group.
• If an approver approves or rejects the transaction, it will count towards the success or failure of the approval rule.

Approval Rule

• All the approval rules (one for each failed condition) must be satisfied before the transaction can be executed.
• The transfer stays in the Pending Approval Status until the required number of approvals to meet all of the approval rules have been received.

Transaction Limits Engine

Financial Institutions (FI) have the flexibility to impose transaction limits at various levels for transfers initiated through the banking application. These include:

• Limits defined at feature level for all online transactions
• Limits defined at role level for a group of online banking users
• Limits defined at company/business level for business customers
• Limits defined at user for each online banking user.

All of these limits may be defined for the following:

• Per transaction value
• Daily transactions value
• Weekly transactions value

Additionally, the limits for business users are further controlled by the individual authorized persons within a business. Every user has a maximum transaction limit (per transaction/daily/weekly), which is imposed by the FI through controls on the business and roles. Within the maximum transaction limit, an authorized person owner can define the following:

• Transaction amounts that can be executed by a user without requiring an approval.
• Transaction amounts that need to be denied entirely.
• Transaction amounts that need to go through an approval process.

Transaction Limits Engine. This is where the transaction limits engine comes in. The transaction limits engine is a service (getTransactionsAmount) which provides the daily and weekly balances of different transactions (bill pay, P2P, own account transactions and more) performed at various levels (company, role, customer, and accounts) and is designed in such a way that any feature that involves transfers of payments can query the transaction engine for a response on how to handle the transaction - either submit/schedule for execution, process for approvals, or deny the submission of the transaction.

See Processing Transaction Limits for more information.

Integrating Temenos Digital Applications with Limits Engine

The following are the objectives to integrate the application with the limits engine:

• Setting up a time zone for a bank based on which all the limits calculations will be done for all transfers supported by the Temenos Digital applications.
• Allowing the selection of only available dates for transfer, based on the time zone set for the bank.
• Using the exhausted limits provided by the limits engine to ascertain the processing for a transfer/payment.

Setting up the server’s time zone

• A configuration is set up that maintains the bank’s time zone.
• During implementations it is possible that the time zone may be fetched from the core/other systems.
• A configuration is set for start of the week. It is Monday by default.

Adjusting calendars for date selection

In the following transfers flows, it is possible for the user to select a date on which the transaction is expected to be executed

• Transfers Flow (Old and New)
  • One Time - Transfer Date (current date is automatically set / a transfer date is set)
  • Series - There is a start date and end date set for all frequencies
• Bill Payments
  • Send On date
• ACH (with or without templates)
  • Effective Date
• P2P transfer (old flow)
  • One Time - Send on date
  • Series - There is a start date and end date set for all frequencies
• In the case of wire transfers, scheduled transactions cannot be created. So, no date selection is allowed currently.

The application adjusts the display of the calendar to show the available dates for the bank’s configured time zone.

When a user submits a transaction

• For a one-time transfer (current date/scheduled date) - Based on the effective date (current or scheduled) according to the bank’s time zone, the daily and weekly limits are calculated to ascertain if the transaction needs to be pre-approved, sent for approval, or auto denied. The front-end application queries the limits engine for the exhausted daily and limit at this point. See Processing Transaction Limits to understand how limits are processed.
  
  
• For a transfer that is scheduled for the current date, the transfer is executed immediately and counted towards the exhausted limit.
• For a transfer that is scheduled for a future date, the transfer is scheduled and counted towards the exhausted balance. If the transaction is canceled, then the exhausted balance is adjusted again.

Getting the Exhausted Limit per Day and Week

The executed transactions along with those pending approval are considered as part of exhausted limits. Consider the scenario:

Daily Limit is 500

Based on the input as customerid, transaction type, and the date

• Get the previous transactions for the specific customerid from the respective table based on the transaction type and the date.
• Calculate the total amount of transactions done, for the day.
• Calculate the total amount of transactions done for the week, based on the starting day of the week. This will include the scheduled and first occurrence of recurring transfers that do not require approval.
• Starting day of the week is configurable in Quantum Fabric Configurable parameters.
• If the configurable parameter is not set, then the default value is taken as Monday.
• The transactions which require approval, and not yet approved, are not considered.

For one-time future transactions and recurring

• The transactions scheduled are checked for future transactions based on the scheduled date, which includes the first occurrence of the recurring transaction as well. The amount is calculated for the day of the scheduled transfer as well as the week. In this case, the week may include the already completed transactions.
• If it is the recurring transaction, then only the first occurrence is checked, that is the start date of the transaction.

Scenarios and sample inputs and outputs of the Transaction Limits Engine

Know the exhaustedLimits of a company

// we should count for all the accounts that are part of this company and the given featureActionId
Input:
{
companyID:"",
featureActionId: "",
date: ""
}
Output:
exhausted limits:
{
Daily: 500
Weekly: 5520
}
			

Know the exhaustedLimits of a role

// we should count for all the users that are part of this Role under the given company 
// and all the accounts belonging to all the users of the role belonging to the company and the given featureActionId
Input:
{
companyID: "",
roleID:"",
featureActionId: "",
date: ""
}
Output:
exhausted limits:
{
Daily: 500
Weekly: 5520
}

Know the exhaustedLimits of a user

// we should count for all the accounts that are accessible to this user and the given featureActionId
Input:
{
customerId:"",
featureActionId: "",
date: ""
}
Output:
exhausted limits:

{
Daily: 500
Weekly: 5520
}

Know the exhaustedLimits of a user of a specific account

// we should count for all the transactions of a given account and featureActionId
Input:
{
customerId:"",
accountId: "",
featureActionId: "",
date: ""
}
Output:
exhausted limits:
{
Daily: 500
Weekly: 5520
}

Limits Engine API

Transaction Limits Engine is a service that provides daily and weekly balances of various transactions performed at different levels (company, role, user, and accounts). The following Fabric service is used to fetch balances.

{
"customerid":"1544995425",
"featureactionid":"p2ptransfers",
"date":"2020-05-28",
"accountid":"200527134643120"
}

{
"Daily": "0.0",
"Weekly": "0.0",
"success": "true",
"opstatus": 0,
"httpStatusCode": 0
}

The featureactionid parameter refers the various type of transaction balances (own account transactions, P2P, bill pay and more) and returns the aggregated value of transaction balances on the date provided as input and transaction balances of that week. The following list is the mapping of featureactionid versus transactions.

• BILL_PAY_CREATE - Bill pays transactions
• P2P_CREATE - P2P transactions
• INTRA_BANK_FUND_TRANSFER_CREATE - Intra-bank transactions
• DOMESTIC_WIRE_TRANSFER_CREATE - Wire transactions
• INTERNATIONAL_WIRE_TRANSFER_CREATE - Wire transactions
• INTER_BANK_ACCOUNT_FUND_TRANSFER_CREATE - Interbank fund transactions
• INTERNATIONAL_ACCOUNT_FUND_TRANSFER_CREATE - International fund transactions
• ACH_PAYMENT_CREATE - ACH transactions
• ACH_COLLECTION_CREATE - ACH transactions
• ACH_FILE_UPLOAD - ACH file transactions
• TRANSFER_BETWEEN_OWN_ACCOUNT_CREATE - Own account transactions

The companyid parameter is optional, and if it is passed in the request input, all the transactions specific to that company (if roleid is passed, there will be filter on role also) are fetched by the TransactinLimitsEngine service and returns the aggregated daily and weekly balances. If the companyid parameter is not provided, then customerid and accountid parameters are considered and return balances specific to the customer.