Modified the minimum time delay for Micro Deposit Verification from 48 hours to 3 hours.

Debit Card

Added new field `addressId` to [Issue Card APIs](/docs/api/cards#issue-card) to support multi-address feature.

![Screen Shot 2023-02-02 at 9.43.54 AM.png](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/Screen_Shot_2023_02_02_at_9_43_54_AM_4e7b45410b.png)

For clients onboarding business customers and using our KYB service, we have enhanced the KYB tab in the portal to show better information on the status of each customer's KYB. The page will now show 3 sections reflecting what our KYB API is doing:

1. Business Identity Validation - this shows results of our validation checks on the information submitted on the Organization ID
2. Associated Party Validation - this shows the KYC status of associated Person IDs to the Organization ID
3. Watchlists Validation - this shows the results of the Organization name and DBA being validated against watchlists

**Why we made this change:**
This enhancement provides more clarity as to a customer's KYB status to help you administer your program. 

Client Portal

Improved KYB tab in the portal

Operational improvement to prevent timeouts on high frequency card authorizations submitted within milliseconds of each other. 

Secured Credit Card

Handle high frequency card authorizations

Virtual Accounts

New virtual accounts now have a routing and account number in preparation of Virtual Accounts Direct Deposit feature.

- ACH Transfers/Returns will be automatically updated to ledger when using new api endpoint [`initiateFundTransfer`](docs/api/ach#initiate-fund-transfer-beta).
- Existing usages on [`createAchTransferRequest`](/docs/api/ach#initiate-ach-transfer) will continue to be manual and should be updated when possible.

 

New API added to simplify workflow for ACH updates to ledger.

Fraud Management

Card transactions are now automatically declined if their Mastercard fraud score is above the allowable threshold.

Added a new YodleeRequestId field to the [Account Linked webhook](/docs/api/webhooks#account-linked), which passes the Yodlee unique request ID to clients of Productfy. This can be used for tracking a FastLink session and connecting it to the data update. 

Data Aggregation

Yodlee Request ID added to webhook

- API to add income information.
    - See [Save Income Information docs](/docs/guides/scc?graphql=mutation%3AsavePersonIncome#step-3-save-income-information) for more details.



New API to support SCC (Secured Credit Card) underwriting.

- New webhook is available to capture this event, see [Statement Ready webhook docs](/docs/api/webhooks#statement-ready) for more detail.


SCC e-statements are now generated at the end of every billing cycle.

- Status code now returns proper 200 status code.



Resolved bug where improper HTTP status code of 404 was returned when no e-statements were found for account. 

- See [SCC Make Payments docs](/docs/guides/scc#step-12-make-payments) for more detail.



New API for making payments on secured credit cards is available.

Fix issue where `saveCompany` API fails due to KVP (key-value pair) data update running before organization is created.

- Now “Settled Balance” is derived from correct “Ledger” balance.

Fix issue where balance data was out of sync due to usage of out of date balance source.

- See [Card Transaction webhook docs ](/docs/api/webhooks#card-transaction)for more detail.

Declined card transactions now have more detail to indicate if a transaction is denied due to the card being frozen.

- Fee events include Annual Fees, Late Fees, and Return Payment Fees.

New transaction type “Fee."

ACH Transfer Returns now include a return code and description to give end users context on why a transfer failed.

Clients can now allow their end-users to add their cards to Apple Pay, Google Pay, or Samsung Pay. Clients can enable this feature with no additional integration work!

![Tokenization_Your Logo goes here.png](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/Tokenization_Your_Logo_goes_here_7b7ff64baa.png)

This feature is available for the [Consumer Secured Credit Card](/docs/guides/scc#root) product. Support for our debit card products is forthcoming.

**How to implement this:**
Check out our [Payment Card Tokenization Implementation Guide](https://user.productfy.io/docs/guides/payment-card-tokenization).

Support for Visa Secured Credit Card in Apple Pay, Google Pay, and Samsung Pay

You can now enable a Balance Refresh feature for your customers with Yodlee-linked accounts, which will allow you to get the most updated balance of an account at any time. 

**Why we made this change**: To allow you to check that your customers with Yodlee linked accounts have a balance sufficient to cover ACH transfers, which will mitigate the risk that your customers make non-sufficient funds (NSF) payments. 

**How to implement this**: Use of this API requires configuration by Productfy, work with your Productfy representative to ensure you are enabled to use this. 

Reduce NSFs with new Balance Refresh feature

We now offer a turnkey, white-label solution for any organization to launch financial products without engineering, compliance, or servicing resources. This solution, which we lovingly named [Latinum](https://memory-alpha.fandom.com/wiki/Latinum), is available in multiple flavors; starting with financial wellness and digital bank, and eventually to include earned-wage access, commercial cards, credit cards, loyalty, and other programs.

![latinumog.png](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/latinumog_4b1cd75d00.png)

This turnkey solution is built on our core API platform, so you can start with it, and roll over to our API platform without any data migration!

**Why we made this change:**
We started Productfy with the thesis "Financial Services is moving to the edge.". This means that more and more people will get financial products where they're most engaged with; not at banks, but where they have meaningful connections. In our [Series A Announcement, we spoke about the need for a white-label solution](https://techcrunch.com/2021/10/08/productfy-raises-16m-to-build-the-shopify-of-embedded-finance/) for clients that don't have the ability to integrate with API's. This is our foray into democratizing the process of creating financial products and empowering any organization to quickly, cost-effectively, and responsibly launch financial products.

**What this means for you:**
If you don't have engineering, compliance, or servicing resources, but want to launch a financial product within a few weeks, then this solution is ideal for you. Even if you already are integrated with us and want to launch a new product line without investing resources, you can still launch the white-label solution as it's integrated into your environment already!

**How to implement this:**
- Step 1: [Fill out the form](https://www.productfy.io/white-label) and our team will work with you to get your information.
- Step 2: Wait, actually, that's it,... you're ready to go live!

White-Label

Turnkey, white-label solution for any organization to become a FinTech

![Pay with card.jpg](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/Pay_with_card_fe1e4449e3.jpg)

Productfy launches the ability for you to accept card payments in your app. Use our hosted payment form to avoid PCI compliance requirements and our API to submit credit and debit card payments to the major card networks. This product includes optional integration to our Virtual Accounts  product, which allows you to automatically credit a virtual account holder’s balance with the amount of funds sent to them. 

Some common use cases for this are:
- Invoicing payments for vendors to pay your customers
- Monthly subscription fees
- Card donations to users of your app

**Why we made this change:**
We hear strong demand from clients that want Productfy to be the all-in-one solution for payments and fintech needs. Since we are already providing bank accounts and cards, we can provide additional value with an integrated merchant payments solution that would not be possible using different vendors. 

**What this means for you:**
You can now accept credit and debit card payments in your app with a solution integrated to the rest of Productfy. 

**How to implement this:**
Talk to your Productfy representative for contract terms. See our implementation guide on this [here](/docs/guides/cardPaymentAcceptance#root). 

Merchant Payments

Merchant payment acceptance now in Beta

The ACH Returns Report is an easy way to see a high-level summary of whether your organization adheres to our bank partner's and the governing body for ACH (NACHA)'s requirements surrounding ACH ratios. This report also enables you to drill down into any of your customers' failed ACH transactions including why transactions fail.

![achgif.gif](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/achgif_8f11414993.gif)


The data available for export currently includes; Transfer Request ID, Transfer Description, Created Transfer Date/Time, when the Transfer was Updated, individual Return Code for each transfer, a Return Description, Requesting Financial Account ID, Requesting Account Holder Type (Person or Organization), Requesting Person ID, Requesting Person First Name, Requesting Person Last Name, NACHA Entry ID, Transfer Amount, Source Financial Institution Name, and Source Account Name–all ready to export for your convenience, as CSV, Excel, or JSON file.

**What this means for you:**
You will need to monitor this to check for warnings the ratio is close to exceeding thresholds.


Compliance

ACH Return Summary Report

We have made changes to the signup flow in the white-label solution that now requires a user of your app to review and acknowledge they have read and accepted the fee disclosures prior to choosing to accept the prepaid account. 

For a user to review and acknowledge they have read and accepted the fee disclosures they must click on the “I have read and accepted Fee Disclosures” hyperlink (as illustrated in the photo below) where they will be prompted to review the entire disclosures page and then click the accept button. 

![Fee Disclosure Checkbox.png](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/Fee_Disclosure_Checkbox_65bc10e6a5.png)

**Why we made this change:** To comply with regulations around consumers acquiring a prepaid account electronically they must view the fee disclosure webpage before choosing to accept the prepaid account. 

**What this means for you:** There’s no additional work needed for you. 

Fee disclosure acceptance checkbox in white-label solution 

Our micro-deposit verification (MDV) now uses same-day ACH to reduce the friction of manually linking an account. Please see the [ACH Guide](/docs/guides/ach#root) for details on same-day ACH.

**Why we made this change:**
We learn from our clients that it's critical for users to be able to link accounts and transact as soon as possible, so we made this switch to reduce the waiting period.

**What this means for you:**
There is no technical work for you. There will be increased fees from MDV transactions.

Faster Micro-Deposit Verifications 

We added the start and end date fields in the financialTransaction query to add additional filtering capabilities.

![FinancialTransactionsByFinancialAccount.gif](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/Financial_Transactions_By_Financial_Account_7a86e2dc1b.gif)


**Why we made this change:**
We pull and store data from financial institutions through Yodlee and make it accessible via our API. When ingesting this data, we have seen that temporal data is inconsistent; within a single financial account, we see transactions, some with transactionDate, some with postingDate, or some with both temporal values populated.

To address this inconsistency, we are exposing a generic "date" field, which Yodlee defines as "postingDate when available, falling back to transactionDate otherwise." This field is currently only present for Yodlee financial transactions.

**What this means for you:**
You can now search transactions from financial institutions with the new date field. We are currently not backfilling this field on existing FinancialTransactions.

**How to implement this:**
Any query that touches financial transaction data retrieval now has this new feature. A few examples are:
- [Get Transactions By Date Range](https://user.productfy.io/docs/api/transactions?graphql=query%3AfinancialTransactionsByFinancialAccount#root)
- [Get Account with the transactions subquery](https://user.productfy.io/docs/api/accounts?graphql=query%3AfinancialAccount#root)
- [FinSight Profile with the financialProfile, financialAccoutns, and transactions subqueries](https://user.productfy.io/docs/api/finsightProfile?graphql=query%3AfinsightProfile#root)


Improve searching for financial transactions from linked financial institutions by adding a date field

You can now view secured credit card info in the client portal. On the Profile tab of a user, you will see the Military Lending Act status of the user. On the Accounts tab, you will see the secured credit card account and the associated collateral. account. This will allow you to better manage the accounts associated with your end users' secured credit cards. 

![collateral Account](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/image_20220721_190609_d1ebebb46c.png)


**What this means for you:**
By logging into the client portal, you now have more tools to review and manage your end users' financial accounts.

Show Secured Credit Card Info in Client Portal

You can now set card controls for virtual or physical cards via the saveCardControls API. This will allow you to create, read, or update spending and authorization controls that are set on the card level. Only one card control can be applied per card. 


**A common use case for this:**
A user of your app wants to issue a virtual debit card for an employee/contractor  that can only be used for Google Ads. They would be able to set a MID restriction to only accept the merchant ID for Google and a specified spending amount for the card.  


**Why we made this change:** To give you and your users the ability to set authorization and spending controls for your virtual or physical cards.  


**How to implement this:** Once a card is created, you can fill out the following fields below:
- **active**:  A boolean field that indicates whether the authorization control is active. Defaulted to true. A required field. 
- **card_id**: A string field token identifying the associated card. A required field. 
- **mids**: An array that contains a list of alphanumeric merchant identifiers. Either this field or amount_limit field are required. 
- **amount_limit**: A decimal field that indicates the maximum monetary sum that can be cleared. Either this field or mids field are required. 
Please see our [Save Card Control API docs](/docs/api/cards#save-card-control) for more information on how to set this up.  

![cardControls_AdobeExpress.gif](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/card_Controls_Adobe_Express_6e893777c1.gif)


**What this means for you:** You can now set card controls for your virtual or physical cards via the saveCardControls API. 

Card controls to limit where and how much users spend

Staying abreast of compliance and banking regulation changes is a core function for us here at Productfy.
Recently there was a NACHA rule change for micro-deposit transactions that are used for manual account linking.

We have implemented and verified the following changes:
- We now use “ACCTVERIFY” in the company entry description field of the ACH file for micro-deposit transactions to clearly identify them for the receiving institution.

**Why we made this change:**
Our clients rely on us to ensure that our micro-deposit offering stays in compliance. 

**What this means for you:**
There's no additional work needed from you to stay compliant.

NACHA rule change for micro deposit transactions

Users who fail frictionless identity verification checks and [knowledge-based authentication (KBA)](/docs/guides/kyc#step-3-knowledgebased-authentication-kba) will now be asked to complete a document verification with facial recognition and liveness test. This new feature scans the ID document (i.e. driver license, passport, etc.) to ensure its validity and compares it with the user's face to ensure that the person is a real user and not a deep fake. This feature is available for both desktop and mobile clients.

![DVS Widget Photo.PNG](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/DVS_Widget_Photo_8962995432.PNG)

**Why we made this change:**
As more people transact on our platform, we are always looking to reduce fraud and improve our ability to keep our users safe.

**What this means for you:**
Previously, a person who cannot complete frictionless identity verification checks and [knowledge-based authentication (KBA)](/docs/guides/kyc#step-3-knowledgebased-authentication-kba) will not be able to proceed. With this new feature, the end-user may submit a document and complete a liveness test on their mobile device. 

**How to implement this:** 
See our [KYC Implementation Guide](/docs/guides/kyc#step-4-document-verification-service-dvs) for details on how to implement this.

Identity verification with ID documents, facial recognition, and liveness test

This change ensures that each transaction relating to the FBO account represents a single NACHA entry.

**Why we made this change:**
An ACH transfer happens as one or more NACHA entries. Although we manage the entire ACH flow for our clients, we rely on the Federal Reserve to move the funds and we get the information from our banking partner's core. Historically, the information we get back can be confusing because the core sometimes grouped multiple NACHA entries together into a single transaction. This change is to ensure that every transaction represents a single NACHA entry.

**What this means for you:**
As an example, these two separate NACHA entries would show up as a single -$.42 transaction. This is how the transactions look now on the client portal, having been split into two:
![AchOperatingAccountForSharing.png](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/Ach_Operating_Account_For_Sharing_a488dbcd23.png)

This change is only visible for our clients in their client portal and not API changes. We wanted to separate each ACH transaction to make it easier for you to understand the transactions on the banking core. There is no action on your end.

Improved ACH transaction data downloads from the FBO account

We now offer a new [Initiate Credit Application API](/docs/api/cards#initiate-credit-application) that can be used to gather underwriting information on credit card applications and to track the date/time each credit card application starts. Tracking the start time of each application is important since regulations require credit card providers to notify customers of any denied credit applications due to incomplete applications. 

This API must be called when a customer's credit card application starts (most likely upon acceptance of Disclosures at the start of the flow). If 7 days go by and a credit card is not issued to the customer, we will trigger the [Incomplete Credit Application Webhook](/docs/api/webhooks#incomplete-credit-card-application) that you can use to send a notification to your customer. 

**Why we made this change:**
Credit card regulations require sending notifications to customers when their credit card application has been denied due to being incomplete. This enhancement allows you to fulfill this obligation in a streamlined and automated way. 

Credit Card Application Tracking

![Screen Shot 2023-01-18 at 3.27.03 PM.png](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/Screen_Shot_2023_01_18_at_3_27_03_PM_0e4362b16f.png)

Our turnkey, configurable white-label application is now able to issue both virtual and physical cards at the same time on the same account. 

**Why we made this change:**
This is useful for clients who want customers to have a plastic card but also have a virtual card available in the app as an alternative to the physical card. 

**How to implement this:**
Speak to your Productfy representative to get activated for this feature. 

Virtual and Physical Cards Available in White-label UI

You can now return the last 4 digits of a card number associated with a financial transaction. 
Easily associate which card made which transaction within an account. 

**A common use case for this would be:**
A user of your app has a virtual account and has multiple cards (eg. a virtual card and a physical card) 
and they can map each transaction with the last 4 digits of a card. 


You can  return **cardLastFourDigits** from the **PaymentCardTransaction** object anywhere you can query transactions:  
- Get Transactions (query financialTransactions)
- Get Transactions By Date Range (query finanicalTransactionsByFinancialAccount)
- Get Financial Account (query financialAccount)

**What this means for you**: You can now retrieve the last 4 digits of a card number via the API.

**Example API Calls**
```graphql title="\"financial transactions\" query"
query financialTransactions {  financialTransactions(personIds: ["PUT PERSON ID HERE"]) {
    __typename
    amount
    id
    ... on PaymentCardTransaction {cardLastFourDigits}
  }
}
```

```graphql title="\"financial transactions by financial account\" query"
query financialTransactionsByFinancialAccount {
  financialTransactionsByFinancialAccount(
    financialAccountId: "INSERT FINANCIAL ACCOUNT ID"
  ) {
    __typename
    edges {
      __typename
      node {
        __typename
        id
        ... on PaymentCardTransaction {
          __typename
          id
          cardLastFourDigits
        }
      }
    }
  }
}
```


Return the last 4 digits of a card number

We have redesigned the KYC tab in our client portal to more clearly show the status of a customer's KYC submission. You can now see more details on the status of each step of our KYC waterfall, including the date/time that it was attempted. 

![Screen Shot 2022-12-21 at 4.19.06 PM.png](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/Screen_Shot_2022_12_21_at_4_19_06_PM_3846832ac6.png)

**Why we made this change:**
KYC is a vital component of onboarding customers and this change will help troubleshoot any failures in KYC. 

**How to implement this:**
This change is automatically available in the Portal on the KYC tab when you are looking into a Person ID. 





KYC tab redesign in Portal

Account statements are now generated for you by the end of each month. Whether you’re a new client or an existing client who previously received statements bi-monthly, statements moving forward will now be generated at the end of the month. 

**Why we made this change**: To streamline all client statements we’ve consolidated our statement generation schedule to the end of the month. 


**What this means for you**: There’s no additional work needed for you. 

Account statements are now generated monthly 

The Military Lending Act dictates that a credit cardholder's active military status must be tracked as they may be eligible for certain protections. We now provide an automated service that checks the military status of any credit card applicant. 

When the **Create Secured Credit Card Account API** is called, we will automatically verify if the customer is in the military and update the **mlaQualified** field in the system. This field is also visible in the Client Portal. 

**Why we made this change:** 
This service streamlines the onboarding process for customers on to a secured credit card and reduces any overhead needed to keep the military status up to date. 

**What this means for you:** 
You no longer have to manually update the military status of customers in the system, our API will do it automatically for you. 

**How to implement this:**
If you're interested in implementing our Secured Credit Card, please talk to your Productfy representative. 

Automated military status updates

We released an embeddable KYC flow for clients who do not want to invest engineering resources to integrate with our platform. This is a continuation of our no-code initiative, Latinum, which aims to support clients who want a white-label, turnkey KYC solution. As with our normal KYC product, it is backed by our BSA/AML team.

![Latinum KYC only Flow-1.jpg](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/Latinum_KYC_only_Flow_1_b87e5faf43.jpg)


**Why we made this change:**
Earlier this month, we launched a white-label debit and deposit account product with rich payments functionality. Since that release, we have seen market demand for a  standalone version of our embeddable KYC product.

**What this means for you:**
If you don't have engineering, compliance, or servicing resources, but need to deploy a scalable KYC solution backed by a team of BSA/AML experts, then this solution is ideal for you.

**How to implement this:**
- Step 1: [Fill out the form](https://www.productfy.io/white-label) and our team will work with you to get your information.
- Step 2: Wait, actually, that's it,... you're ready to go live!

Embeddable KYC Flow

Productfy now provisionally supports the ability for all types of business customers to pass through our fully compliant Know-Your-Business service. Banking regulations require that we obtain a certain amount of data on each business customer, validate that they aren't on any watchlists, and that the information they provide is legitimate.  Passing KYB is required to approve business end users for accounts or ACH money movement. This is all done in a streamlined way through the **executeKyb API**. For more information please see our [KYB Implementation Guide](/docs/guides/kyb#root). 

**Why we made this change:**
Previously we only supported automated KYB for sole proprietorships and required manual work for other types of businesses. Now we can support all types of business in an automated way via our API. 

**What this means for you:**
You can now onboard any type of business and get them validated for KYB through our **executeKyb API**. 

**How to implement this:**
Please see the  [KYB Implementation Guide](/docs/guides/kyb#root) for more information on how to set this up. 


Full Know-Your-Business (KYB) Service Now In Beta

We enhanced our [card transaction webhook ](/docs/api/webhooks#card-transaction) to provide reason for the authorization declines. There are various ways a reason can occur including insufficient funds, timeouts, or fraud score being too high.

Here are some sample webhook message bodies:
```json title="Sample body for timeout"
{
  "id": "Pfy_WebhkEv-12345678",
  "status": "I",
  "eventPayload": {
    "type": "authorization",
    "state": "DECLINED",
    "amount": "2.8",
    "reason": "timeout",
    "merchant": { "name": "Test Merchant" },
    "accountId": "Pfy_FinA-m237A5CkY3jEK3q2",
    "reasonCode": "97",
    "ledgerImpact": "negative",
    "gpaOrderState": "ERROR",
    "paymentCardId": "Pfy_PymtCard-1234567890123456789012",
    "transactionId": null,
    "pendingBalance": 349,
    "settledBalance": 371.7,
    "availableBalance": 344.5,
    "additionalInformation": null,
    "previousTransactionId": null
  },
  "triggeringEventTs": "2022-04-04T21:02:08.744Z",
  "createdTs": "2022-04-04T21:02:09.368Z",
  "triggerType": "PymtCard",
  "callbackUrl": "https://testing.mydomain.com/webhook-endpoint"
}
```

```json title="Sample body for insufficient funds"
{
  "id": "Pfy_WebhkEv-12345678",
  "status": "I",
  "eventPayload": {
    "type": "authorization",
    "state": "DECLINED",
    "amount": "1500.8",
    "reason": "Not sufficient funds",
    "merchant": { "name": "Test Merchant" },
    "accountId": "Pfy_FinA-1234567890123456",
    "reasonCode": "1016",
    "ledgerImpact": "negative",
    "gpaOrderState": "DECLINED",
    "paymentCardId": "Pfy_PymtCard-1234567890123456789012",
    "transactionId": null,
    "pendingBalance": 349,
    "settledBalance": 371.7,
    "availableBalance": 344.5,
    "additionalInformation": null,
    "previousTransactionId": null
  },
  "triggeringEventTs": "2022-04-04T21:02:08.744Z",
  "createdTs": "2022-04-04T21:02:09.368Z",
  "triggerType": "PymtCard",
  "callbackUrl": "https://testing.mydomain.com/webhook-endpoint"
}
```


**Why we made this change:**
We want to give our clients the ability to take action or give a better explanation to their users based on the reasons for a decline.

**What this means for you:**
You can now build additional logic off of the "reason" field in the decline webhook message.


Authorization Decline Reasons in Webhook Messages

We have made changes to the statements we generate as an ongoing exercise to continue to ensure that we are in compliance. This is core to our compliance-as-a-service offering. There are five changes:
- Rename "General Statement Policies' header to 'Error Resolution Notice'
- Add a telephone number.
- Be more explicit about the type of transfer.
- Be more explicit about the type of to and from accounts.
- Be more explicit about the name of the entity doing the transfers.

**Why we made this change:**
Our clients rely on us to ensure that the statements we generate for end-users are in compliance.

Updates to Generated Account Statements

We updated the way we map Yodlee account statuses to make the linking process more resilient. It is unlikely that you will have to make any code changes and would only notice that the accounts are being linked with greater reliability. Our clients rely on us to pull financial data without having to integrate with the data aggregators, which is time-consuming and error-prone. This is our continuation of work to harden the data aggregation functionality at scale.

**Why we made this change:**
Previously we had FinancialAccount.accountLinkingStatus coded up to the FinancialAccountLinkingStatus enum which contained statuses that pertained to the existence of the account within Yodlee, as well as data aggregation statuses. When we pull down updateEligibility field from Yodlee, we mapped the status DISALLOW_UPDATE to FinancialAccountLinkingStatus.INACTIVE, which prevented the FinancialAccount’s currentBalances, currentPendingBalances, and currentSettledBalances fields from updating. As it turns out, the DISALLOW_UPDATE status is temporary and not reliable.

Because of the problematic nature of that Yodlee updateEligibility field, we are splitting out the data aggregation statuses such that this accountLinkingStatus field will only pertain to account existence within Yodlee. We plan to have a future enhancement to the API to introduce the data aggregation statuses as a separate field.

**What this means for you:**
Now FinancialAccountLinkingStatus will mean:
- ACTIVE - Synchronized between Productfy and Yodlee.
- INACTIVE - Accounts that are CLOSED or TO_BE_CLOSED from Yodlee's viewpoint.
- UNLINKED - No longer exists in Yodlee.
- WAITING_FOR_FIRST_DATA_UPDATE - Initializing. Waiting for Yodlee data update webhook which finalizes selected accounts.

All other fields would be deprecated: CREDENTIALS_REQUIRED, MANUALLY_OBSOLETE, UNDER_MAINTENANCE.

If you are using the deprecated fields, you should plan to stop using those fields. If you are not using these fields, there is nothing you need to do.

Improve resiliency for Yodlee financial account linking

You can now retrieve the usage type field of a virtual account to determine whether the account is for personal or business use.

The financial accounts API now returns FinanicalAccountUsageType and has affected the following APIs:
- [Get Financial Account (query getFinancialAccount)](/docs/api/accounts?graphql=query%3AfinancialAccount#root)
- [Get Financial Accounts (query getFinanicalAccounts)](/docs/api/accounts?graphql=query%3AfinancialAccounts#root)

**Why we made this change:** The financialAccountUsageType field is a key field that dictates whether a virtual account is a personal or business account. Exposing this data in our APIs will help clients have greater visibility into how their accounts are configured.

**What this means for you:** You can now retrieve the usage type via the financial accounts API.

New field available in financial account APIs

We've made enhancements to our Organization entity to return KYB data. An example of the data return in the enhanced entity:
```json title="Sample organization with KYB data"
{
  "id": "Pfy_O-123456789",
  "kybData": {
    "status" : "INITIALIZED",
    "lastCheckedDate" : "2022-05-18T02:50:39.923Z"
  }
}
```
**Why we made this change:**
As we continue to enhance our platform to support commercial use cases, we want to make it easier for developers to access KYB data.

**What this means for you:**
You can now retrieve KYB data from the organization object.

**How to implement this:**
You will need to have KYB enabled in your environment. You can look at how to implement KYB via the [implementation guide](/docs/guides/kyb#root).

Additional KYB Data Accessible via API

Continuing on our work from last month, we enhanced our [card transaction webhook ](/docs/api/webhooks#card-transaction) to provide a webhook message for declined authorizations due to a high likelihood of a fraudulent transaction.

**Why we made this change:**
We want to give our clients the ability to take action or give a better explanation to their users for a decline due to a likelihood of fraud.

**What this means for you:**
You can now build additional logic off of the "reason" field in the decline webhook message.

Webhook for declined card authorization based on fraud score

The SCC balance is now available via the API. Productfy generates SCC statements in a compliant manner so you don't have to. However, if you want to display the balance information outside of a PDF statement, you can retrieve it by API.

Statement data can be accessed through the statements query:
```graphql title="Access through the \"statements\" query"
query statements($accountId: ID) {
  statements(accountId: $accountId) {
    endDate
    id
    startDate
    statementUrl
    statementBalance
    statementDueDate
  }
}
```

```json title="Sample response from \"statements\" query"
{
  "data": {
    "statements": [
      {
        "endDate": "2021-11-15",
        "id": "Pfy_AccStmt-12345678901234567890123",
        "startDate": "2021-10-15",
        "statementUrl": "https://url.com/patt/to/statement1",
        "statementBalance": 100.0,
        "statementDueDate": "2022-12-25"
      },
      {
        "endDate": "2022-02-15",
        "id": "Pfy_AccStmt-12345678901234567890ABC",
        "startDate": "2022-01-15",
        "statementUrl": "https://url.com/patt/to/statement2",
        "statementBalance": 100.0,
        "statementDueDate": "2022-03-25"
      },
      {
        "endDate": "2022-03-15",
        "id": "Pfy_AccStmt-12345678901234567890xyz",
        "startDate": "2022-02-15",
        "statementUrl": "https://url.com/patt/to/statement1",
        "statementBalance": 100.0,
        "statementDueDate": "2022-04-25"
      }
    ]
  },
  "extensions": {
    "responseTs": "2022-06-09T13:50:32.962+05:30",
    "sessionKey": null,
    "transactionId":
      "Pfy_T-123456789012345678901234567890123456789",
    "success": true,
    "responseCode": "20000000",
    "responseMessage": "Generic OK"
  },
  "errors": null
}
```

Statement data can be accessed through the accounts query:
```graphql title="Access through the \"accounts\" query"
query ($id: ID!) {
  financialAccount(id: $id) {
    id
    accountName
    accountStatus
    statementBalance
    statementDueDate
  }
}
```

**Why we made this change:**
We want to empower you to display statement balance information outside of the generated PDF's.

**What this means for you:**
You can now retrieve statement data via the API.

**How to implement this:**
You can retrieve this information through the [Get Account](/docs/api/accounts?graphql=query%3AfinancialAccount#get-account) and the [Statements](/docs/api/transactions?graphql=query%3Astatements) queries.

Expose Secured Credit Card Balance in API

Our system now enforces a unique SSN per client. We do this to continue to strengthen our fraud management and KYC solutions as many of our clients rely on our Compliance-as-a-Service and Fraud Management-as-a-Service offerings

**Why we made this change:**
We want to prevent end-users from enrolling or opening accounts with the same client with the same SSN so that we can reduce fraud and make improve our ability to support end-users. 

**What this means for you:**
The [Create Person](/docs/api/customer#create-person) or [Save Person Information](/docs/api/customer#save-person-information) mutations will enforce uniqueness on the SSN field and return an error that SSN is already enrolled.

**How to implement this:**
There no new work on your end if you are integrating with the [Create Person](/docs/api/customer#create-person) or [Save Person Information](/docs/api/customer#save-person-information) mutations as a new client.


Unique SSN per client

The last 4 digits of a card number are now displayed in the transaction details of a financial transaction in the white-label solution. This update makes it easier to associate which card made which transaction within an account. 

**A common use case for this would be**: 
A user of your app has a virtual account and has multiple cards (eg. a virtual card and a physical card) and they will now be able to map each transaction with the last 4 digits of the associated card. 

**Why we made this change**: A user of your app can now associate which card (if they have multiple) made a specific transaction which can help in returns or fraud situations.

**What this means for you**: There’s no additional work needed for you. 



Displaying the last 4 digits of a card number in white-label solution

Virtual cards are now available as part of Productfy’s configurable white-label solution. We have also built email messages to accompany the new feature.

![Welcome to Latinum!](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/image_20220815_173804_11c7a056ea.png)
![Virtual Card Management](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/image_20220815_173850_5a0839bc93.png)
![The user's welcome email](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/image_20220808_164029_e049a71597.png)


**Why we made this change:**
For clients looking to take advantage of a fully-compliant and pre-approved fintech application, the option is now available to display virtual cards in the app (full card number, CVV code, expiration date). Additionally, virtual cards can be used in digital wallets like Apple Pay, Google Pay or Samsung Pay. 

**What this means for you:**
If you don't have engineering, compliance, or servicing resources, but want to launch a pure digital financial product within a few weeks, then this solution is ideal for you!

**How to implement this:**
- Step 1: [Fill out the form](https://www.productfy.io/white-label) and our team will work with you to get your information.
- Step 2: Wait, actually, that's it,... you're ready to go live!

Virtual cards available in white-label solution

Since our release of statements within the accounts tab in the client portal, there is no longer a need to show statements within the documents tab. Statements within the documents tab have now been deprecated.

**What this means for you**: There’s no additional work needed for you. 

Statements deprecated in the documents tab in the client portal 

Users now have the option to set PINs on virtual debit cards.

**A common use case for this would be:**
When a user is prompted for a PIN at a POS terminal in a store while using Apple/Google/Samsung Pay they can now enter the PIN they’ve set on their virtual card. 

**Why we made this change:**
To give users that utilize Apple/Google/Samsung Pay the ability to set PINs on their virtual cards

**How to implement this:**
You can use the existing [setPaymentCardPin](/docs/guides/debit?graphql=mutation%3AsetPaymentCardPin#step-4-activate-card-and-set-pin) API on a virtual card. 

**What this means for you:**
There’s no additional work needed for you. 


Setting PINs on Virtual Cards

We continue to improve the client portal to give you greater control and visibility into your users' financial accounts. We've made the following improvements to the Accounts tab in the portal:
- Easier navigation between different accounts belonging to the same user
- Clearer display of account details for Virtual Accounts and Linked Accounts
- Displaying Available Balance 

![See transactions and transactions to update the balances of a virtual account](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/Transactions_And_Create_Transactions1_379372b3e7.png)

**What this means for you:**
By logging into the client portal, you now have more tools to review and manage your end users' financial accounts.

Improved financial account management screens 

We released a set of new screens to help our clients better administer their programs including:
- A  redesign of the end-user profile to better show KYC, account, card, and transactional data
- A new organization screen to help our B2B clients manage their business end-users
- A redesign of the ACH administrative screen

We updated our search screen with additional columns that our clients have been asking for and split up the tabs between consumer end-users and business end-users.
![image-20220617-203632.png](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/image_20220617_203632_37548ed61c.png)

Starting with a new look and feel for the end-user profile, you can easily navigate to see details of their interactions and assets on the platform.
![image-20220617-204041.png](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/image_20220617_204041_fea4113311.png)

Continuing with our investments for our B2B clients, we've released an additional screen to help you manage your business end-users more efficiently
![image-20220617-203930.png](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/image_20220617_203930_da017dbf7a.png)

We've also made it easier for you to review individual ACH transfers
![DuyAchDemo.png](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/Duy_Ach_Demo_fd902f62d4.png)


**Why we made this change:**
We want to enable our clients to become better program managers and help them be successful in building and scaling their programs.

**What this means for you:**
Your administrators can now better manage their programs through the portal.


New person, organization, and card administrative features in the client portal

We released [an API](/docs/api/kyc#kyb) to support KYB for sole proprietors that supports compliance requirements to approve businesses for accounts and money movement.

**Why we made this change:**
As we continue to grow our commercial card issuance and baking products, we wanted to provide you with an easier way to execute KYB since it is a prerequisite to opening an account or issuing cards. 

**What this means for you:**
You can now execute the entire KYB process for businesses that are sole proprietors without a doing-business-as (DBA) name through our API's.

**How to implement this:**
Please see the  [KYB Implementation Guide](/docs/guides/kyb#root).

Automated Know-Your-Business (KYB) for Sole Proprietors

We added additional field descriptions to the provide better description for you to integrate with our mutation to save companies. This is an important mutation for use with our KYB program.

![Sample explanation of the formationDate field](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/Screen_Shot_2022_07_22_at_9_51_06_PM_1_383fb11a66.png)


**What this means for you:**
As we expand our support for commercial programs, we are enhancing our documentation to help you integrate with ease.

Developer Docs

Enhancements to documentation of saveCompany mutation 

We have exposed the date/time of a transaction settling to the [FinancialTransaction query](/docs/api/transactions?graphql=query%3AfinancialTransactions) so that you can clearly understand what is happening with the account. This is the same date that is used in account statements. 

**What this means for you:**
For settled transactions, you can now retrieve the settlementTs from the FinancialTransaction object.

Settlement timestamp available in to FinancialTransaction API

You can now access account statements in the client portal. When accessing an account from the Accounts tab, you will now see a Statements sub-tab with links to each account's PDF statement. We continue to make these investments to help you manage your program with greater ease.

![Access account statements in Statements tab](https://productfy-strapi-production.s3.us-west-2.amazonaws.com/Statments_tab_550d405691.gif)

**What this means for you:**
By logging into the client portal, you now have more tools to review and manage your end users' statements from financial products and services you offer.

Access Account Statements in Client Portal

We now offer the ability for you to send Productfy data on which customers have accepted which disclosures in your app. This is required at two different points in time:

- At time of account opening
- With each ACH initiated in your app


**Why we made this change:**
To make compliance with banking regulations easier, we created an API and flow to help reduce the burden for your team to build compliant financial products.


**What this means for you:**
During account opening, you can now call the [Disclosure Acceptance API](/docs/api/utilities?graphql=mutation%3AsaveDisclosureAcceptance#root) to send in this data, and during ACH transactions, there is now a disclosureAcceptance data object available in the [Initiate ACH Transfer Request](/docs/api/ach?graphql=mutation%3AcreateAchTransferRequest#initiate-ach-transfer) and [Initiate Funds Transfer](/docs/api/ach?graphql=mutation%3AinitiateFundTransfer#root) APIs.


**How to implement this:**
Please fill out the fields as indicated below:

- acceptanceTime: The current date/time (in PST)
- disclosureId: The disclosure ID provided by Productfy or enter ‘ACH’ for the ACH authorization
- disclosureType: The disclosure type associated with the disclosure ID
- ipAddress: The IP address of the customer
- organizationId or personId - The ID associated with the organization or person on Productfy

Disclosure acceptance improvements

A Merchant Category Code (MCC) is a unique four-digit number assigned by the card networks to a business based on the goods or services offered by the business. With our latest update you can now limit user spending on virtual or physical cards based on the type of goods or services provided by merchants via the saveCardControls API. 


**A common use case for this would be:** A user of your app wants to issue a virtual debit card for an employee that can only be used for Travel Agencies and Tour Operators. They would be able to set an MCC restriction to only accept the merchant category code for Travel Agencies and Tour Operators and a specified spending amount for the card. 

**Why we made this change:**
To give you and your users the ability to set more broad spending controls based on the type of goods or services provided by a merchant. 

**How to implement this:**
With a new or existing card control, you can now set the following field:
-  **mccs**: An array that contains 1 or more merchant category codes. Either the mccs, merchantIds, or amount_limit field are required. 

Please see our [Save Card Control API docs](/docs/api/cards#save-card-control) for more information on how to set this up.  

For reference, here’s a comprehensive MCC listing, refer to page 24 of the [Visa Merchant Data Standards Manual](https://usa.visa.com/content/dam/VCOM/download/merchants/visa-merchant-data-standards-manual.pdf) or page 37 of the [Mastercard Quick Reference Booklet—Merchant Edition](https://www.mastercard.us/content/dam/public/mastercardcom/na/global-site/documents/quick-reference-booklet-merchant.pdf).

**What this means for you:** You can now set spending controls on your virtual or physical cards based on the type of goods or services provided by merchants via the saveCardControls API. 

Release Notes

Filter