Does CU*Answers have to comply with the recently published Apple Pay push provisioning rules?
Apple recently provided their Issuer Functional Requirements for Apple Pay. Apple stated that by January 15, 2026, if you have an app you must implement in-app provisioning.
Our initial interpretation is that Apple’s requirements are at the card-processor level; if a credit union today wishes to enable Apple Pay, the credit union enables the solution at the card processor and the member manually puts in the card in the Apple Pay wallet. However, we further spoke with several card processors who advised their understanding is if the credit union has a relationship with Apple Pay and has any mobile app, a push provisioning solution is required.
As you know from our Leadership Conference, push provisioning is already a focus for CU*Answers, and we have begun active development of this product now with a vendor that can support all EFT vendors. As we finalize the plans for the product, including the costs associated with the solution, we will be advising credit unions of its availability. We anticipate onboarding to include coordination with the vendor as well as a deployment update to your mobile app.
Further information about the requirements can be made to our Cards and Payments team at cardsandpayments@cuanswers.com.
Explain the way that CBX secures funds for debit card authorizations?
The process can vary a bit according to the vendor, but here’s a discussion about how it works for credit unions on the CO-OP network, as an example.
In most cases, debit card authorizations create a Misc. Secured Shares record on the member’s account to hold the funds. When the actual transaction comes in, this record is automatically deleted. (There are exceptions to this rule, such as gas purchases.)
Previously, debit card authorizations would add a hold to an independent debit authorization file and put a comment on the account. The hold would delete automatically after two business days during EOD processing, regardless of when the actual transaction was posted to the member’s account. That meant that funds might be held longer than necessary. The system is now designed so that funds will be held only until the transaction is posted. (If the transaction never actually comes through, the Misc. Secured Funds record will still be deleted after two business days.)
By using a Misc. Secured Funds record, the hold will affect the available balance on the member’s account for all activity, not just for other debit card authorizations. That means that everywhere a member’s available balance is used (teller posting, Inquiry/Phone, home banking/audio response, share draft posting, ACH, etc.) will reflect the funds being held. The philosophy is: “If you spend the money, a hold is put on the funds so you can’t spend it again anywhere else.”
(Remember that in online banking and audio, like everywhere else in CBX, the difference between available balance and actual balance includes things like misc. secured funds, uncollected funds (check holds), and even account freezes. This is explained in detail in the online help available in It’s Me 247 online banking.)
CBX has a feature that lets you view a history of activity in the Misc. Secured Funds file, including when the record was created, and when it was purged when the live transaction was posted. Use F15-Secure on the Account Inquiry screen, then F18-Sec Funds Hist to access this inquiry. This will help with research should a member question why funds were unavailable at a particular point in time. Just remember also to check Uncollected Funds (check holds) records by using F14-Uncollected on the Account Inquiry screen, then F18-UncHist.
All of our debit card switches are consistent in how they handle authorizations, assuming the authorizations are handled at our end by CBX and not by the switch itself, of course, as may be true in some instances.
Will we know if a bill is to be paid by ACH or check in “It’s Me 247” Bill Pay (Fiserv)? If so, how? How will stop payments be handled?
The most important thing to understand is when the bill will be received, not how it will be paid. Payment methods are determined by the relationship between Fiserv and the biller and are subject to change. When scheduling a payment, the system automatically pre-fills the earliest payment date the biller can receive the payment. The date can be altered to a future date, but not an earlier date. Once a payment begins processing, you will be able to view the payment method in history. If the item is a member draft, stop payments should be placed like any other member draft. The check number can be viewed in history. If the item is electronic, a case will need to be created through Customer Care.
What choices do I have for controlling whether or not my ANR negative balance limits are used when authorizing and paying debit card and ATM transactions?
The settings that control how this works are part of Tool #558 NSF/Overdraft Transfer Configuration, on the Overdraft Protection Activation screen. There are two flags for ANR/courtesy pay: “Use Negative Balance Limits for Authorizations” and “Use Negative Balance Limits for Posting”. They control whether the member’s ANR limit is added when determining the available balance amount.
Does CU*Answers produce the IRS Form 1099-K form that states that companies that process credit and debit card payments are required to submit?
No. This pertains to merchant card programs where the merchant is collecting payments for services and goods sold. Since we do not run merchant programs on our platform, this reporting requirement does not apply to CU*Answers.
Why would a member who has elected to opt out per Reg. E receive a non-return fee on a debit card transaction?
In many cases, the reason an opted-out member receives the non-return fee is because this transaction is a recurring payment. Recurring transactions are not covered by the Reg. E Opt In/Out requirements. You can identify this by the * after the DBT/WDR trans description on the member’s transaction history. Recurring transactions are posted, and a fee occurs even if the member is Opted Out.
With Co-Op national shared branching, is there a way to identify transactions as cash or check deposits, the way in-network ATMs show in transaction history?
When a cash deposit is made at a Smart ATM, we are able to place a $ symbol within the secondary transaction description, and the BSA program uses this to identify currency. However, shared branch network activity is different. Transactions via Co-Op national shared branching can include both cash and checks as part of the funds in. Adding a notation to the transaction records would be difficult as it’s not a perfect correlation between funds and the transaction. For that reason, we use the message file to pull out the current portion of the deposit for BSA.
As for ATMs, mixed deposits are not supported so the transaction itself will be either cash or check, not a combination. This allows us to add that indicator directly onto the transaction record.
