#1: Some institutions assume the "FI" aggregate (which includes the FID
and ORG) will always be sent and they do validation against it. Note that
this aggregate can optionally be sent by a client, but because some
organizations assume that these are being sent by only be the "major"
third-party "supported" applications (e.g. Intuit or Microsoft) they might
only validate the ones they know about ... and always expect to see them.
Therefore, you may need to consider if and how to send those in your
requests. This FI aggregate, from your perspective, would be roughly
analogous to the client APPID APPVER ... in that you would need to have
valid ones to pass in or you might get blocked by a particular FI's OFX
server.

#2: Another remote (very unlikely reason) possibility could be due to some
of the new MFA features (now available in the newer specification of OFX)
that an FI might choose to optionally implement which changes the OFX
security model a bit. But if this occurs, it would tend to be limited to
just banks and possibly credit unions. It's a remote possibility, but it
could prevent your client-side KMyMoney behavior to stop working if it's not
capable of interacting with MFA-enabled OFX servers.

Code: Select all

const QByteArray MyMoneyOfxConnector::accountInfoRequest(void) const
{
  OfxFiLogin fi;
  memset(&fi,0,sizeof(OfxFiLogin));
  strncpy(fi.fid,fiid().latin1(),OFX_FID_LENGTH-1);
  strncpy(fi.org,fiorg().latin1(),OFX_ORG_LENGTH-1);
  strncpy(fi.userid,username().latin1(),OFX_USERID_LENGTH-1);
  strncpy(fi.userpass,password().latin1(),OFX_USERPASS_LENGTH-1);

  char* szrequest = libofx_request_accountinfo( &fi );
  QString request = szrequest;
  // remove the trailing zero
  QByteArray result = request.utf8();
  result.truncate(result.size()-1);
  free(szrequest);

  return result;
}